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Preface 

The  Initial  Idea  of  this  study  was  to  Improve  the 
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I  would  like  thank  Maj  Joseph  Litko,  my  thesis 
reader,  for  his  help  and  assistance  with  the  formulation 
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I  appreciate  the  effort  of  both  Lt  Col  Rowell  and  Maj 
Litko  for  the  many  hours  they  spent  proofing  this  document 
and  making  valuable  suggestions  for  this  thesis. 

I  would  like  to  thank  the  analysts  at  the  Hq  Mac 
Analysis  Group  for  their  help  and  assistance,  especially 
Maj  Mark  Donneley,  Maj  William  Ewing,  Capt  Steve  Knot, 
and  Capt  Mark  Fowler . 

Lastly,  but  perhaps  most  importantly,  I  would  like  to 
thank  my  family.  I  thank  my  wife  Peggy  for  her  love, 

devotion,  and  understanding  through  this  trying  time.  ion  PcmT 
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Abstract 

"The  primary  objective  of  this  research  is  to  improve 
and  package  a  previously  developed  mathematical 
programing  model  to  increase  its  likelihood  of  acceptance. 
The  model  departs  from  the  normal  measure  of  effectiveness 
of  airlift,  measuring  ton  miles  per  day,  and  allocates 
combat  and  airlift  resources  to  maximize  combat  power 
delivered  to  the  objective  area  (thus  the  name  ACAR).  The 
package  selected  to  build  around  this  model  was  that  of  a 
Decision  Support  System  (DSS). 

This  thesis  has  produced  a  working  prototype  DSS  that 
can  assist  Air  Force  and  Army  Planners.  The  primary  method 
of  design  for  this  DSS  was  adaptive  design.  This  thesis 
presents  one  complete  cycle  of  that  approach.  The  concept 
mapping  technique  was  used  to  identify  two  kernel  problems 
for  this  DSS  to  study.  The  three  components  of  this  DSS, 
the  data  base,  the  model  base,  and  the  man  machine 
interface,  are  described  in  detail. 

The  data  base  component  consists  of  the  various  screen 
displays  which  contain  tabular  data.  The  tables  group 
similar  items  together  and  contain  the  input  required  to 
the  model  base  component. x  The  heart  of  this  DSS  is  the 
model  base  which  has  been  adapted  from  previous  thesis 
efforts.  Lotus  123  was  used  as  a  DSS  generator  and  to 
generate  the  input  for  the  linear  programing  software 
called  XA.  This  DSS  is  a  user  friendly  analytical  tool. 


ACAR,  A  DECISION  SUPPORT  SYSTEM  TO 
OPTIMIZE  THE  ALLOCATION  OF  COMBAT 
AND  AIRLIFT  RESOURCES 


I.  Introduction 


...when  the  U.S.  applies  force,  it  must  be  able  to 
apply  it  expeditiously.  Hence,  high  priority 
should  be  given  to  creating  the  transport  capacity 
and  support  which  will  enable  the  U.S.  to  deploy 
substantial  numbers  of  troops  to  Third  World 
trouble  spots  in  very  short  periods  of  time... 
possession  of  an  airlift  force  capable  of  deploying 
substantial  numbers  of  troops  quickly  is  an 
essential  step  in  lengthening  the  nuclear  fuze... 
[to  seize  the]  "window  of  opportunity" ...  the 
commander  must  have  the  right  forces  at  the  right 
place  and  at  the  right  time... the  flexibility  to 
maneuver  to  many  places  around  the  world  is  the 
essence  of  a i r 1 i f t . [ 5 : 12 3-12 4 , 1 31 ] 

These  words  by  General  Duane  H.  Cassidy,  Commander 
in  Chief,  Military  Airlift  Command,  set  the  stage  for 
the  requirement  for  airlift  to  be  able  to  deliver  men 
and  equipment  as  close  as  possible  to  the  battle  area  as 
quickly  as  possible. 


Motivation 


Airlift  requirements  are  rooted  in  Air  Force 

doctrine.  Maneuver  is  a  principle  of  war  emphasized  by 

fundamental  Air  Force  doctrine  (8:ch2-5  to  ch2-9). 

The  use  of  maneuver  allows  commanders  to  position 
their  forces  in  places  and  at  times  that  surprise 
the  enemy,  so  that  the  enemy  forces  are  unable  to 
counter,  to  respond  effectively.  To  be  effective, 
maneuver  requires  precise  execution  and  timing, 
concentration  of  force  and  adequate  logistical 
support  ( 8 :ch5-7  ]  , 


Maneuver  is  the  reason  for  airlift's  existence.  Airlift 

offers  the  mobility  required  to  be  decisive  in  war  (3:7). 

This  is  evident  in  the  definition  of  airlift's  basic 

mission,  taken  from  the  United  States  Air  Force  Fact  Sheet 

Number  82-83  as  cited  by  Bullard: 

...to  airlift  personnel  and  material  in  support  of 
military  objectives  for  two  missions:  strategic  and 
tactical.  Strategic  airlift  ( i nter thea ter  )  is 
sustained  air  transportation  between  operational 
areas,  or  between  the  continental  United  States  and 
overseas  areas.  Tactical  airlift  (intratheater)  is 
deployment,  airborne  assault,  air  evacuation  and 
air  supply  within  an  operational  area. [3:7] 

Lieutenant  Colonel  Bullard  in  a  1983  War  College 

paper  gave  a  good  analogy  to  airlift.  He  stated  that 

airlift  capability  should  be  "viewed  as  an  unbroken 

circle"  of  continuous  support  for  the  user.  He  suggested 

that  classifying  airlift  into  strategic  and  tactical  may 

obscure  this  capability;  and,  that  air  mobility  should  be 

thought  of  as  "one  system  capable  of  traversing  the  entire 

circumference  of  the  circle  (3:8)." 

with  the  importance  of  airlift  established,  the 

background  leading  up  to  current  airlift  requirements 

and  how  these  requirements  are  measured  is  explored. 

Then  an  argument  for  using  combat  power  delivered  versus 

ton  miles  per  day  as  a  measurement  of  effectiveness  for 

airlift  requirements  is  provided. 

Background 

During  World  War  II,  airlift  had  finally 
demonstrated  that  it  was  a  viable  means  of  resupply.  In 


1945  the  Air  Transport  Command's  3700  aircraft  had 
airlifted  275,000  passengers  and  100,000  tons  of  cargo 
worldwide  (18:75).  According  to  Dr.  Leary  in  an  article 
entitled  Strategic  Airlift  Past,  Present ,  and  Future, 
the  India-China  resupply,  called  "The  Hump,"  was  a  very 
dramatic  example  of  what  airlift  can  accomplish  (18:75). 
General  Cassidy  states,  "the  Hump  was  the  greatest 
airlift  in  history  --  up  to  that  time"  (5:115). 

Shortly  after  World  War  II  airlift  again 
demonstrated  its  enormous  value  when  the  Soviets 
blockaded  West  Berlin.  The  United  States  airlift 
resupply  of  West  Berlin  allowed  defeat  of  the  Russian 
blockade  "without  resorting  to  war"  (18:77). 

After  WWII  all  of  the  DOD  drew  down  its  forces,  but 
at  the  same  time,  crises  around  the  world  showed  the 
United  States  that  Communist  Bloc  aggression  was  a  real 
threat  (33:3-4).  The  United  States  undertook  plans 
for  "flexible  response"  to  be  able  to  deter  this 
aggression.  At  the  same  time,  budget  constraints  forced 
the  Air  Force  to  make  reductions  in  its  troop  carrier 
wings  (33:4). 

In  the  early  sixties,  as  the  airlines  were  building 
up  with  modern  fleets  of  aircraft,  the  Air  Force  was 
still  being  forced  to  draw  down  especially  in  the 
ability  to  airlift.  It  was  suggested  that  the  airlines 
could  handle  the  military  airlift  requirements.  In  1960 
a  special  subcommittee  of  the  House  Armed  Services 


Committee  was  appointed  to  look  into  national  airlift 
(18:78).  The  committee  reported  that  airlift  was  a 
weapon  system,  that  airlines  would  not  fill  the  need,  and 
that  airlift  was  "seriously  inadequate"  (18:78). 

Also  in  1960,  the  Military  Air  Transport  Service 
held  an  airlift  exercise  called  operation  "Big  Slam." 

This  exercise  was  highly  successful  in  the  amount  of 
tons  it  moved  but  at  the  same  time  demonstrated  large 
inadequacies  of  airlift  ( 5  : 118-119; 20 : 2 ) .  It  seems  the 
Air  Force  could  move  the  troops  but  not  in  the  time 
required  by  the  Army.  Also,  the  airlift  was  unable  to 
move  the  equipment  the  troops  would  most  likely  need. 

The  airlift  fleet  was  only  able  to  move  one  small  tank, 
some  artillery,  and  little  ammunition  (5:116). 

Improvements  were  made  with  the  purchase  of  new  jet 
aircraft  which  increased  our  capability  considerably, 
but  with  increased  capabilities  came  Increased 
commitments  and  a  new  shortfall  developed  (20:2). 

Since  the  early  sixties,  our  national  strategy 
has  been  one  of  flexible  response.  Flexible  response 
allows  the  President  to  choose  the  weapons  and  methods 
to  respond  to  the  enemy's  advances.  A  key  element  of 
the  flexible  response  strategy  is  mobility  (5:120). 

In  1981  the  Congress i ona 1 ly  Mandated  Mobility  Study 
identified  an  urgent  requirement  for  the  United  States 
to  develop  the  capability  to  airlift  66  million  ton 
miles  per  day  of  cargo  ( 5 :  1 20 ;  18  :  8 1 ;  29 : 58 ; 3 0  :  2  )  .  Ton 


miles  per  day  cargo  capacity  is  figured  by  multiplying 
the  speed  of  a  particular  aircraft  by  the  number  of 
hours  per  day  the  plane  can  be  expected  to  fly,  then 
multiplying  this  number  by  the  maximum  tons  of  cargo 
that  can  be  hauled  on  the  longest  leg  of  the  mission. 
These  ton  miles  per  day  per  aircraft  are  summed  over  all 
different  types  of  aircraft  available,  to  get  an  overall 
ton  mile  per  day  capacity  for  the  entire  airlift  fleet. 
The  minimum  goal  of  66  million  ton  miles  per  day  was  a 
fiscal  compromise  and  did  not  fully  satisfy  any  of  the 
four  scenarios  used  in  the  Congressionally  Mandated 
Mobility  Study  ( 29 : 58 ; 30 : 11 ) . 

All  articles  mention  the  66  million  ton  miles  per 
day  requirement  of  the  Congressionally  Mandated  Mobility 
Study,  but  a  Government  Accounting  Office  report,  dated 
March  1987,  brings  out  an  Important  fact  of  the  study. 
The  report  states: 

The  goal  of  airlift,  however,  is  to  deliver  combat 
troops  and  equipment  as  close  to  their  final 
destination  as  possible,  while  maintaining  unit 
integrity.  In  light  of  this  goal,  the  CMMS 
concluded  that  DOD's  intertheater  airlift 
capability  was  lacking  not  only  in  quantity,  but 
also  in  quality  (30:11). 

The  gao  further  noted  that  airlift  needed  the  ability  to 
deliver  outsize  cargo  to  small  forward  airfields,  closer 
to  the  final  destination  (30:11). 

In  the  Annual  Report  to  the  Congress  for  Fiscal 
Year  1987,  Secretary  Of  Defense,  Caspar  Weinberger 
stated  that  the  current  Administration  defense  policy 
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was  to  "ensure  a  balance  of  forces  adequate  for 
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credible  deterrence"  (32:37). 

Airlift  capability  adds  to  deterrence.  The 
Government  Accounting  Office  report  stated  that  "the 
ability  to  move  forces  with  sufficient  equipment  and 
supplies  to  distant  locations  may  make  military  action 
by  opposing  forces  less  likely"  (30:10).  The  same 
sentiment  is  held  by  Wendzel  who  believes  airlift  is  a 
deterrent  to  aggression  and  aggression  left  unchecked 
creates  more  aggression  (33:15-17).  Ulsamer  agrees 
and  states  that  airlift  just  might  be  what  is  necessary 
to  keep  a  conflict  from  escalating  into  a  high  level 
(29:58).  He  further  asserts  that  having  the  capability  to 
project  the  force  just  might  deter  "Soviet  military 
adventur ism" ( 29 : 58 ) .  General  Cassidy  says  that,  airlift 
should  give  commanders  "unrestrained  mobility  and 
flexibility  so  that  they  may  prevent  battle  or  that  they 
may  surely  win  in  battle"  (5:131).  The  United  States 
overall  military  strategy  is  one  of  deterrence  and 
airlift  plays  a  main  role  in  this  deterrence. 

Weinberger  points  out  the  importance  of  the  airlift 
fleet  as  part  of  the  "Strategic  Mobility  Forces" 

(32:52).  He  states,  "the  inherent  deployment 
flexibility  of  aircraft  makes  them  a  key  element  of  our 
rapid  deployment  forces"  (32:212).  He  discusses  the 
importance  of  deploying  our  forces  when  and  where  they 
are  needed  (32:235).  Weinberger  also  points  out  the 


plans  for  the  C-17  aircraft  to  "deliver  forces  over 

intercont  inental  distances  directly  to  austere  forward 
locations"  (32:236).  These  comments  emphasize  the 
importance  of  delivering  the  men  and  equipment  directly 
to  where  they  are  needed,  near  the  front.  This  "direct 
delivery"  capability  should  greatly  enhance  our 
capabilities  to  project  our  forces  around  the  world. 
Delivery  would  be  by  airdrop  or  airland  at  a  forward  air 
field  (29:61-62). 

In  the  United  States  Military  Posture  FY  1987 
publication,  the  Organization  of  the  Joint  Chiefs  of 
Staff,  also  state  the  importance  of  airlift  to  the  rapid 
deployment  of  forces  (23:66).  They  further  discuss 
the  capabilities  of  the  C-17  and  the  Importance  of 
delivering  troops  and  all  types  of  cargo  to  small 
austere  airfields  (23:66).  These  small  austere 
airfields  would  be  close  to  the  final  destination  or 
to  staging  areas  where  forces  would  be  assembled 
and  then  moved  to  the  combat  area  (30:22). 

It  is  very  important  for  Department  of  Defense  and 
airlift  planners  to  have  the  capability  to  analyze  and 
study  airlift  requirements.  The  previous  discussions 
have  shown  the  need  for  airlift  to  have  the  capability  to 
directly  deliver  combat  men  and  equipment  to  the  combat 
area.  With  the  procurement  of  the  C-17  the  United  States 
will  have  that  capability.  The  analytical  models,  used  by 
planners  of  airlift,  all  use  ton  miles  per  day  as  measure 


o£  effectiveness  for  airlift  (17).  With  the  importance  of 
direct  delivery  of  combat  units  established,  it  will  be 
helpful  to  planners  to  have  a  model  that  uses  combat  power 
delivered  to  the  front  as  a  measure  of  effectiveness  for 
airlift. 

The  Model.  In  1984  Army  Captain  James  Cooke,  an 
AFIT  student,  developed  an  analytical  model  to  look  at 
the  rapid  deployment  of  combat  forces.  This  model  looks 
at  both  the  airlift  capabilities  and  the  combat  units  to 
deliver  and  finds  the  optimal  mix  of  aircraft  required  to 
meet  specified  goals  of  force  delivered  (6:viii). 

There  were  212  variables  and  136  equations  in  Captain 
Cooke’s  model  (6:viii).  He  also  demonstrated  how  to 
use  response  surface  methodology  to  do  a  full  parametric 
sensitivity  analysis. 

Later  that  same  year.  Captain  David  Tate,  another  AFIT 
student,  picked  up  on  the  same  model  and  tried  to 
incorporate  some  of  the  recommendations  Cooke  had  made. 

Tate  created  a  fortran-based  interactive  program  to  make 
the  model  user  friendly.  His  front  end  to  the  model 
built  the  problem  as  he  had  intended;  but,  he  could  not 
get  his  routine  to  talk  to  the  goal  programing  package  he 
wanted  to  use  to  solve  the  problem  (28:ch6-6).  Tate's 
formulation  of  the  model's  constraints  included  a  couple 
of  improvements  over  Cooke's.  Tate  removed  the 
restriction  that  only  bulk  cargo  could  be  moved  by 
intratheater  airlift  and  the  restriction  that  all  units 


moving  on  their  own  power  move  at  the  same  rate  (28:ch7-.3) 
Tate  made  several  recommendations  for  further 
research.  First,  he  recommended  that  attrition  of 
aircraft  and  troops  be  incorporated  into  the  formulation. 
Second,  a  model  representing  the  current  inventory  and 
capabilities  should  be  developed.  Third,  more  sensitivity 
analysis  to  include  ranging  of  the  right  hand  side  values 
of  the  constraints  should  be  accomplished.  And  lastly, 
the  allocation  routine  PAGP,  the  routine  that  was  supposed 
to  solve  the  goal  programing  problem,  should  be 
corrected  to  work  with  the  program  he  developed  (28:ch7-4) 
As  follow  on  work  in  1986,  Major  Raymond  Haile  took 
Cooke's  methodology  and  built  a  model  that  maximizes  the 
combat  power  delivered  to  the  theater  commander 


( 1 4 : i x ) .  Haile's  model  uses  288  variables  and  168 
equations  (14:lx).  Halle's  model  also  uses  response 
surface  methodology  to  do  a  sensitivity  analysis  on  a  Far 
Eastern  theater  of  operations  scenario  (14:8). 

Haile  made  recommendations  for  further  refinements  to 
the  model.  He  noted  that  attrition,  as  included  in  his 
model,  did  not  take  into  account  the  proper  mix  of 
aircraft  type,  mission  type  and  period  of  the  deployment 
and  could  be  modeled  better  if  specific  threat  scenarios 
were  included  in  the  model  (14:135).  Also,  Haile  pointed 
out  that  the  mix  of  airlift  forces  recommended  as  a  result 
of  the  model  was  highly  scenario  dependent  and  that  a 
matrix  generator  to  build  the  linear  model  would  make  it 


easier  to  change  the  scenario  (14:135). 

There  are  other  areas  where  the  model  seems  to 
display  some  weakness.  First,  the  model  was  limited  to 
four  five-day  periods,  due  to  computer  size  and  run  time 
requirements,  instead  of  a  more  desirable  thirty  one-day 
periods.  Thirty  days  is  considered  the  normal  surge 
airlift  requirement.  Second,  the  model  is  restrictive  in 
that  it  only  considers  one  aerial  port  of  debarkation 
(APOD)  and  one  forward  operating  location  (FOL)  to  be  used 
during  the  surge  airlift. 

This  model  departed  from  maximizing  total  ton  miles 
per  day  as  the  measure  of  airlift  effectiveness  and 
captured  the  real  requirements  on  airlift  by  maximizing 
combat  power  delivered  to  the  objective  area.  Combat  power 
delivered  attempts  to  capture  how  airlift  can  affect  the 
battle  by  direct  delivery  of  combat  forces  to  the  front. 
This  model  values  forces  delivered  early  and  to  the  front 
more  highly  than  forces  delivered  later  and  to  rear  areas 
(14:131-134).  It  captures  the  time  value  of  forces 
de 1 i vered . 

Statement  of  the  Problem 

The  model  developed  by  Cooke  and  refined  by  Tate  and 
then  Haile  has  not  yet  been  implemented  by  Headquarters 
Military  Airlift  Command  (HQ  MAC)  or  for  that  matter  by 
anyone  in  the  DOD  to  analyze  theater  airlift  requirements. 
Analyst  in  the  HQ  MAC  Analysis  Group  have  expressed 


interest  in  using  this  model.  The  problem  is  that 
the  model  in  its  current  mathematical  form  is  not  user 


friendly  and  does  not  model  attrition  properly.  The 
primary  objective  of  this  research  is  to  answer  the 
question,  "How  can  the  model  be  improved  and  packaged  to 
increase  the  likelihood  of  acceptance  into  the  HQ  MAC 
Analysis  Group's  library  of  analytical  methods?” 

The  Method 

The  linear  programing  model  as  presented  by  Cooke, 

Tate,  and  Haile  exists  in  a  form  which  requires  a  trained 
analyst  to  input  raw  data  into  the  model,  in  whatever 
computer  language  he  or  she  has  available,  and  then 
interpret  the  raw  output.  Its  use  is  limited  by  the  fact 
that  it  is  a  stand  alone  model  requiring  a  trained  analyst 
to  prepare  and  input  data,  run  the  model,  and  interpret 
the  results.  A  preferred  form  to  this  model  might  be  that 
of  a  decision  support  system. 

A  decision  support  system  (DSS)  is  any  system  (in 
this  case  a  computer  based  system)  that  assists  the  user 
with  the  making  of  decisions.  The  DSS  has  three 
components:  a  data  base,  a  model  base,  and  a  man  machine 
interface  (31).  A  DSS  provides  a  user  friendly  atmosphere 
where  the  decision  maker  can  study  the  problem  with  assis¬ 
tance  from  the  model  and  the  data  base.  A  central  theme 
in  the  design  and  building  of  any  DSS  is  the  adaptive 
design  approach.  The  details  of  DSS  design  and  the  adaptive 
design  approach  are  presented  in  the  next  chapter. 
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Research  Objectives 


1.  To  use  adaptive  design  in  building  a  decision 
support  system  (DSS)  which  incorporates  this 
mathematical  programing  model. 

2.  To  solicit  specific  user,  HQ  MAC  Analysis  Group, 
r equ i rements . 

3.  To  improve  the  modeling  of  attrition. 

4.  To  adapt  the  model  to  accommodate  a  spreadsheet  to 
input  parameters  and  output  results. 

5.  To  develop  a  matrix  generator  to  easily  generate  the 
input  matrix,  objective  function,  and  right  hand  side 
for  the  mode  1 . 

6.  To  identify  the  size  of  formulation  required  to 
expand  the  model  from  the  current  four  five-day 
periods  to  thirty  one-day  periods. 

7.  To  identify  the  requirements  to  expand  the  model  to 

include  more  than  one  aerial  port  of  debarkation 
(APOD)  and  forward  operating  location  ( FOL )  . 

S.  To  develop  the  formula  that  will  determine  the  size 

of  the  problem  and  how  the  problem  grows  in  size  with 
each  of  the  changes  to  be  made. 

'3.  To  identify  with  the  help  of  the  user  and  a  technique 
called  concept  mapping  an  initial  problem  to  solve  as 
an  illustration  of  the  application  of  this  DSS. 


1  ? 


Scope  of  Effort 

The  objective  of  this  research  Is  to  build  a  prototype 
DSS  to  be  used  by  HQ  MAC  Analysis  Group.  The 
identification  of  the  initial  problem  to  assist  the 
decision  maker  with  uses  the  concept  mapping  technique, 
and  the  identification  of  the  overall  design  of  the  DSS 
uses  the  adaptive  design  technique.  This  DSS  is  a  user- 
friendly  front  end  for  the  mathematical  model  and  utilizes 
a  spreadsheet  application  package  as  boch  DSS  and  matrix 
generators . 

Changes  to  the  formulation  of  the  previously 
developed  mathematical  programing  model  are  made  when 
necessary.  These  changes  were  identified  as  either 
recommendations  in  the  previous  efforts,  or  were  based 
upon  Interviews  with  HQ  MAC  analysts. 

Organization 

Chapter  II  is  a  literature  review  of  the  methodology 
and  techniques  used  in  developing  this  DSS.  Chapter  III 
is  the  first  of  three  chapters  that  cover  the  three  main 
parts  of  this  DSS.  This  first  part  Is  the  data  base  used 
in  the  DSS.  The  chapter  describes  the  data  used  for  the 
model,  the  origin  of  the  data,  and  the  format  of  the  data 
as  used  in  the  DSS.  Chapter  IV  describes  the  model  base 
used  in  this  DSS.  Detailed  descriptions  of  the 
mathematical  programing  model  and  the  improvements  made 
to  earlier  formulations  are  given.  Chapter  V  discusses 
the  third  part  of  the  DSS,  the  man  machine  interface. 


This  chapter  presents  the  attributes  of  this  DSS  that  make 
it  user  friendly,  such  as  the  menus  and  explanations  of 
the  menu  selection  built  into  this  DSS.  Chapter  VI 
presents  a  discussion  of  the  findings  from  the 
implementation  of  the  kernel  problem.  It  also  contains  a 
summary  of  conclusions  and  recommendations. 


II.  Methodology 


Introduction 

This  chapter  presents  a  literature  review  of  the 
methodology  and  techniques  used  to  develop  this  DSS.  It 
begins  with  the  definition  of  DSSs .  Next,  a  discussion  of 
why  a  DSS  is  needed  for  the  previously  developed 
rnat  he  mat  lea  1  model  is  pr  r-e.ented  .  The  chapter  continues 
with  a  presentation  of  the  character  ist  ics  of  DSSs  and  is 
followed  by  a  discussion  of  tne  adaptive  design  process. 

The  presentation  on  adaptive  design  includes  the  four 
stages  of  adaptive  design  and  the  key  concepts  involved  in 
those  stages.  This  chapter  concludes  with  a  discussion  of 
the  three  components  of  the  DSS. 

What  is  a  Decision  Support  System? 

Sprague  and  Carlson  in  their  book  Building  Effective 
Decision  Support  Systems,  describe  the  real  definition  of  a 
DSS  as  being  somewhere  between  "interactive  computer  -  based 
systems  that  help  decision  makers  utilize  data  and  models 
to  solve  unstructured  problems,"  a  restrictive  definition, 
and  "any  system  that  makes  some  contribution  to  decision 
making,"  a  broad  definition  (26:4).  AFIT  Lt  Col  Skip 
Valusek  in  a  course  on  Decision  Support  Systems  defines  a 
DSS  as  a  system  that  supports  the  mental  processes  of 
judgement  and  choice  (31).  With  a  definition  of  DSS  In 
mind  the  next  question  is  why  is  one  needed  in  this  case. 


Why  Decision  Support  System? 

All  three  models  developed  by  Cooke,  Tate,  and  Haile 
required  the  use  of  a  mainframe  computer  at  AFIT.  Cooke 
and  Haile  both  relied  on  the  mainframe  to  solve  their 
mathematical  formulation  program  and  to  develop  the 
response  surface  equations  to  use  in  their  analysis.  Their 
use  of  a  mainframe  made  using  the  model  difficult  for  a 
number  of  reasons.  For  example,  an  analyst  had  to  be  very 
familiar  with  the  specific  package  being  used.  Also, 
putting  the  data  In  the  required  format  was  very  time 
consuming.  In  fact,  one  of  the  reasons  why  Cooke  and  Haile 
included  response  surface  equations  was  to  speed  up  the 
process  of  making  predictions  with  the  results  of  their 
models  ( 6  :  96; 14  : 11-12  )  .  Tate  used  the  mainframe  for  the 
FORTRAN-based  front  end  to  his  model.  Tate's  objective  was 
to  build  a  user  friendly  interactive  front  end  that  allowed 
the  input  of  data  either  interact i vely  or  through  data 
files.  Had  his  program  worked  with  the  routine  required  to 
solve  the  mathematical  goal  programming  formulation  the 
input  of  data  would  have  been  easier  although  time  sharing 
and  output  analysis  would  still  require  a  considerable 
amount  of  time  (28:ch7-4). 

The  main  objective  of  the  current  research  effort  is 
to  develop  a  microcomputer -based  Decision  Support  System 
(DSS)  to  support  Air  Force  and  other  interested  DOD  decision 
makers.  Cooke  recommended  that  the  model  be  developed 
into  a  user-friendly  computer  package  (6:132).  Haile 
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recommended  that  a  matrix  generator  be  developed  to  build 

the  input  matrix  for  the  linear  program  (14:135).  This 
current  methodology  incorporates  these  recommendations  and 
then  goes  further  by  pursuing  a  number  of  DSS  concepts. 

The  reason  for  developing  this  DSS  on  a  microcomputer 
is  because  of  the  proliferation  of  microcomputers  in  the 
Air  Force.  No  longer  does  analysis  have  to  be  restricted 
to  studies  and  analysis  organizations  with  access  to 
mainframe  computers.  Analysts  can  work  with  a  DSS  such  as 
the  one  developed  in  this  thesis  at  literally  thousands  of 
locations  where  micr ocomputer s  are  available.  Also,  DSSs 
allow  mathematical  models  to  be  used  by  nonanalyst 
managers  and  novice  computer  users.  For  example,  the 
current  DSS  might  be  used  by  Air  Force  planners  trying  to 
plan  how  many  sorties  of  what  type  aircraft  are  required, 
or  by  Army  planners  trying  to  decide  what  mix  of  army  units 
is  required  to  maximize  firepower  and  meet  the  minimum 
required  anti-tank  and  defensive  frontage  capabi 1  it ies . 

With  the  motivation  for  the  development  of  this  DSS 
established,  the  next  section  discusses  the  character ist ics 
of  a  DSS  that  this  research  exploits. 


characteristics  of  DSSs . 

Sprague  and  Carlson  list  four  char acter  ist ics  of  DSSs. 
Each  of  these  characteristics  and  how  the  DSS  developed  in 
this  research  fits  these  character i st i cs  will  now  be 
described.  DSSs  tend  to  be  aimed  at  the  semi -structured  to 


unstructured,  underspecified  problems  (26:6).  This 


characteristic  means  that  it  is  hard  to  say  ahead  of  time 
what  the  problem  is  and  how  exactly  to  solve  it.  The 
current  DSS  is  originally  being  designed  to  answer  a 
specific  kernel  problem  (a  problem  identified  as  the 
initial  problem  to  help  the  decision  maker  solve).  Other 
uses  of  the  DSS  and  other  problems  to  be  solved  with  this 
DSS  are  difficult  to  specify  ahead  of  time. 

A  second  character ist ic  is  that  a  DSS  attempts  to 
combine  the  use  of  models  with  traditional  data  access  and 
retrieval  (26:6).  The  DSS  developed  in  this  thesis  uses 
data  bases  to  supply  the  parameters  used  in  the  linear 
program  model.  For  example,  the  numbers  of  aircraft, 
capabilities  of  aircraft,  attrition  rates,  and  number  of 
units  available  for  the  deployment  are  all  parameters  that 
are  in  the  data  base  and  used  by  the  linear  programming 
mode  1 . 

The  third  characteristic  Is  that  properly  constructed 
DSSs  are  interactive  and  easily  used  by  noncomputer  people 
(26:6).  The  current  DSS,  which  uses  microcomputer  CRT  and 
keyboard  for  inputs  and  CRT,  disk  drive,  or  printer  for 
outputs,  is  interactive.  The  development  of  menus  to  lead 
the  user  through  the  data  bases  and  the  output  of  the 
linear  programming  model  requires  the  user  to  know  very 
little  about  the  software  used  for  this  DSS.  The  menus 
appear  at  the  top  of  the  spreadsheet  and  an  explanation  of 
the  highlighted  menu  item  appears  on  the  line  directly 
below  the  menu.  The  user  can  select  a  menu  item  by  either 


using  the  first  letter  of  that  item  or  by  using  the  arrow 

keys  to  highlight  and  return  key  to  select.  A  data  base 
item  can  be  changed  using  the  arrow  keys  to  select  the  item 
and  then  typing  the  new  entry,  which  then  appears  on  the 
top  line  of  the  spreadsheet,  upon  pressing  return  the 
change  is  inserted.  A  notepad,  for  the  user  to  leave 
notes  to  himself,  and  a  hookbook,  for  the  user  to  leave 
notes  for  the  system  designer  and  builder,  are  included  and 
can  be  selected  from  any  menu.  These  two  capabilities  are 
not  only  user  friendly  but  also  help  satisfy  the  next 
character istic  of  a  DSS,  that  of  being  adaptable. 

The  last  character ist ic  of  a  DSS  that  Sprague  and 
Carlson  identify  is  that  a  DSS  is  flexible  and  adaptable  to 
changes  in  the  decision  making  environment  and  approach  of 
the  user  (26:6).  The  largest  stumbling  block  for  the 
adaptability  of  any  system  is  the  communication  between  the 
user,  the  designer,  and  the  builder  of  the  system  (16:16-22). 
The  notepad  and  hookbook  described  earlier  allow  the  user 
to  keep  track  of  his  thoughts  over  a  period  of  time  and 
allow  the  user  to  leave  messages  for  the  system  designer 
and/or  builder.  Another  aspect  of  the  current  DSS  that 
increases  its  adaptability  is  that  as  new  uses  are 
discovered  a  new  menu  can  be  be  added  and  a  new  macro  can 
be  created  to  accomplish  the  new  task.  This  can  be  done 
without  affecting  any  previously  developed  menus  or  macros. 
This  modularity  was  identified  as  a  necessary  attribute  for 
the  selection  of  a  DSS  generator  (the  software  and  hardware 


used  to  create  the  DSS)  in  a  article  entitled  Adaptive 
Design  for  DSS  Development  (1:27).  This  fourth 
character ist ic  of  a  DSS,  adaptive  design,  is  really  the 
heart  of  the  entire  DSS  design  process. 

Adaptive  Design 

The  primary  method  for  identifying  changes  to  be  made 
in  the  DSS  will  be  the  adaptive  design  approach.  Adaptive 
design  consists  of  taking  a  crude  model,  using  it  and 
subsequently  improving  it  through  the  tour  stages  of 
design.  Sprague  and  Carlson  point  out  that  in  adaptive 
design  these  four  stages  --  requirements  analysis,  design, 
development,  and  implementation  --  are  iteratively  repeated 
in  a  relatively  short  time  (26:15).  The  amount  of  time  is 
dependent  on  the  system  being  developed;  but  for  example, 
if  normal  computer  system  development  would  take  say  three 
to  five  years  then  an  adaptive  design  cycle  should  take  say 
three  to  seven  months  (31). 

Requirements  Analysis .  The  first  stage  of  the  four 
stages  of  development  is  requirements  analysis.  One  method 
that  can  be  used  for  requirements  analysis  uses  the  idea  of 
concept  mapping  to  identify  the  kernel  problems. 

Concept  Mapping.  Capt  Mike  McFarren 
developed  the  basis,  justifications,  and  procedures  for 
concept  mapping  in  problem  analysis  (22:1416)  .  He 
described  concept  mapping  as  a  way  to  "identify  the  key 
factors  and  ideas  of  a  problem  space... [and  show]  their 


relationships  to  each  other  (22:40)."  Concept  mapping  is 

used  to  identify  the  kernel  problem  from  which  to  begin  the 
adaptive  design.  The  procedures  for  concept  mapping 
consist  of  interviewing  the  user  to  capture  the  user's 
understanding  of  the  problem  and  mapping  the  user's 
understanding  of  the  problem  on  paper  or  chalkboard.  To 
map  the  concepts  the  interviewer  places  the  events 
(concepts)  identified  by  the  user  in  circles  or  rectangles 
on  the  board  and  connects  the  events  with  linking  words 
obtained  from  the  user.  After  the  concept  map  is 
completed,  the  key  events,  the  kernels,  can  be  identified 
by  the  user.  The  user  identifies  one  or  more  of  the 
kernels  to  becomes  the  Initial  requirement  for  the  design 
of  the  DSS  during  the  first  iteration  of  adaptive  design. 
For  this  DSS  an  interview  was  conducted  with  Capt  Mark 
Fowler,  an  analyst  with  the  HQ  Military  Airlift  Command's 
Analysis  Group  (12).  A  concept  map  was  constructed  and 
appears  as  figure  1.  Two  kernels  were  identified  as 
initial  problems  for  the  DSS  to  address. 

Kernels  for  this  DSS.  The  initial  problems  identified 
for  development  in  this  DSS  were  both  related  to  the 
allocation  of  airlift  resources.  The  first  problem  would 
be  to  study  how  the  model  would  use  the  number  of  each 
different  aircraft  available  to  fly  different  types  of 
missions.  These  different  types  of  missions  include 
intertheater  (US  to  APOD),  intertheater  (US  to  FOL ) 
airland,  intertheater  (US  to  FOL)  airdrop,  and  intratheat.er 


(APOD  to  FOL ) .  The  second  kernel  was  to  study  the  problem 
of  determining  how  the  aircraft  are  used  to  satisfy 
different  cargo  requirements.  The  question  was  to  find  out 
how  many  sorties  of  what  type  cargo  was  required  in  each 
period  by  each  aircraft  type.  These  types  of  cargo  include 
outsize,  oversize,  bulk,  personnel,  and  supplies. 

A  further  discussion  of  the  results  of  the  DSS  designed  for 
these  kernel  problems  Is  in  chapter  VI. 

Design.  After  the  kernel  problem  or  problems  have 
been  Identified  as  the  initial  requirement  for  the  DSS,  the 
design  phase  begins.  A  very  effective  technique  for  the 
design  of  the  DSS  is  the  ROMC  approach  developed  by 
Sprague  and  Carlson  (26:101-107). 

ROMC  Approach  for  Design.  The  four  components  of 
the  ROMC  approach  are  representations,  operations,  memory 
aids,  and  control  mechanisms  (26:101-107).  These 
components  make  up  an  approach  that  allows  the  DSS  design 
to  identify  capabilities  while  being  process - i ndependent 
(26:101).  in  other  words  the  DSS  is  designed  to  allow 
flexible  approaches  so  that  multiple  users  can  use  the 
system  to  suit  their  decision  processes.  The  next  four 
sections  cover  each  of  these  components  and  how  this  DSS 
design  uses  that  approach. 

Representations  and  Storyboard ing . 
Representation  is  very  important  because  it  has  to  do  with 
communication.  Thoughts  are  often  most  easily  expressed  in 
the  form  of  a  picture.  Re lat i onsh i ps  can  be  expressed  and 


communicated  quickly  in  the  form  o£  a  graph.  All 
commun i cat i on  is  done  in  terms  of  some  sort  of 
representation  be  if  words,  pictures,  graphs,  or  numbers 
(26:102).  Representation  is  the  means  by  which  the  user 
through  menus,  commands,  and  data  base  changes  communicates 
information  with  the  machine  and  the  means  by  which  the 
machine  through  screen  displays  communicates  information  to 
the  user.  An  interesting  technique,  new  to  computer  system 
design,  for  performing  the  representation  phase  of  system 
design  Is  storyboarding.  Andriole  states  that,  "a 
storyboard  is  a  sequence  of  displays  that  represents  the 
functions  that  the  system  may  perform  when  formally 
implemented  (2:3)."  A  storyboard  becomes  a  powerful  tool 
in  the  representations  phase  when  the  storyboards  are 
designed  with  the  user's  inputs  or  even  by  the  user 
himself.  At  this  phase  it  may  be  preferable  if  the  system 
builders,  the  information  system  personnel,  were  not 
involved  with  the  design  (31).  To  capture  the  true 
requirements  for  the  system,  the  concept  map  identifies  the 
kernel  problem  to  solve  and  the  storyboard  identifies  the 
screen  displays  that  the  user  can  understand  and  gain  the 
most  information  from.  After  these  steps  are  complete,  the 
system  can  be  handed  over  to  the  system  builders  so  the 
first  prototype  can  be  built..  For  the  DSS  developed  here 
the  storyboard  consists  mainly  of  the  display  of  the 
menus,  the  data  tables,  and  the  output.  The  storyboard  for 
this  DSS  is  presented  in  the  figures  throughout  this 


thesis.  The  data-base  storyboards  are  in  chapter  III.  The 
menus  and  output  storyboards  are  in  chapter  v. 

Operations.  The  operations  component  of 
the  DSS  design  approach  are  the  manipulations  required  of 
the  representations  and  should  correspond  to  the 
operations  that  the  user  must  go  through  to  make  a 
decision.  These  operations  fall  into  three  human 
Information  processing  categories  which  are  intelligence, 
design,  and  choice  (26:103).  Intelligence  operations  are 
operations  such  as  data  gathering  and  validating,  problem 
diagnosis  and  structuring,  and  objective  identification 
(26:104).  Design  operations  include  data  manipulation, 
generating  alternatives  and  reports,  and  quantifying 
alternatives  and  objectives  (26:104).  Choice  operations 
include  generating  statistics  and  simulating  results  of 
alternat i ves,  choosing  among  alternatives,  and  explaining 
alternatives  and  choices  (26:104).  These  operations  should 
be  considered  and  included  in  the  DSS  when  warranted.  This 
DSS  incorporates  many  of  these  operations.  Operations  are 
provided  for  updating  all  the  data  bases.  The  data  is 
automat ica 1 ly  manipulated  by  the  Lotus  123  spreadsheet  to 
build  the  matrix  for  the  linear  programming  software.  The 
output  of  the  model  is  again  manipulated  by  the  Lotus  123 
spreadsheet  to  present  the  results  in  a  way  to  answer  the 
kernel  problem.  These  operations  are  built  Into  the  DSS 
and  are  transparent  to  the  user. 

Memory  Aids.  Memory  aids  are  necessary 


because  the  average  human  being  is  capable  of  storing  only 
seven  plus  or  minus  two  pieces  of  information  in  short  term 
memory  and  must  exert  a  large  amount  of  effort  to  store 
information  in  his  or  her  long  term  memory  (25:81-85). 

What  this  means  to  the  designer  of  a  DSS  is  that  for  the 
DSS  to  be  user-friendly  the  DSS  should  not  require  the  user 
to  remember  large  amounts  of  information  such  as  commands 
or  even  to  remember  their  location  in  the  DSS.  The  DSS 
needs  to  have  memory  aids  that  keep  the  user  on  track, 
where  the  user  would  like  to  be,  freeing  up  the  user's  short 
term  memory  to  work  on  current  tasks.  In  the  DSS  developed 
for  this  thesis  menus  are  used  to  lead  the  user  through  the 
DSS,  and  prompts  on  the  screen  displays  remind  the  user  of 
the  commands  to  return  him  to  certain  menus.  Notepad  and 
hookbook  areas  are  provided  as  a  way  for  the  user  to  jot 
down  thoughts  that  come  to  him  or  her  thereby  freeing  up  the 
user's  short  term  and  long  term  memory. 

Control  Mechanisms.  Control  mechanisms  are 
simply  aids  that  help  the  user  control  the  DSS 
(26:106).  These  aids  include  but  are  not  limited  to 
menus,  libraries,  help  menus,  training  programs  and 
operations  that  can  change  any  default  values  of  the  DSS 
(26:106-107).  The  menus  in  the  current  DSS  are  the 
main  control  mechanism  that  help  the  user  operate  this  DSS. 
On  the  line  under  the  menus  appears  an  explanation  of  the 
function  of  the  highlighted  menu  item.  A  short  user's 
manual  also  accompanies  this  DSS  to  explain  how  to  get  Into 


and  out  of  the  DoS  and  how  to  tun  the  model. 

Development  Phase.  The  DSS  1 s  actually  built  In 
the  development  phase .  Sprague  and  Carlson  point  out  three 
typical  approaches  to  the  actual  development,  of  the  DSS. 

The  first  of  these  is  what  they  ca 1 1  the  "quick-hit 
(26:61)."  This  approach  uses  tools  that  are  currently 
available  or  can  be  purchased  easily  to  build  the  first 
DSS .  This  approach  can  lead  to  a  throw  away  DSS  that  Is. 
only  good  for  one  purpose.  When  the  next  iteration  is 
identified  a  new  DSS  might  need  to  be  built  (26:61).  The 
next  approach  is  the  "staged  development  approach  (26:61)." 
This  is  an  iterative  approach  and  seems  to  fit  best  with 
the  adaptive  design  approach.  One  disadvantage  of  this 
approach  is  that  more  time  is  spent  on  the  initial 
development  building  a  more  universal  DSS  that  allows  for 
easier  follow  on  changes.  The  last  approach  actually 
builds  a  complete  DSS  generator  and  is  called  the  "complete 
DSS  (26:61)"  approach.  This  complete  DSS  can  take  a  very 
long  time  to  develop,  six  to  ten  years,  and  has  the 
greatest  risk  of  technological  obsolescence  (26:63).  Also, 
with  a  system  taking  that  long  to  develop,  requirements 
determination  would  be  next  to  impossible.  The  approach 
used  is  situation  and  organization  dependent. 

In  the  development  of  this  DSS  the  staged  development 
approach  was  used.  All  four  stages  of  design  were 
completed  in  a  relatively  short  time  with  the  initial  DSS 
given  to  the  user  to  use  and  provide  feedback  to  the 


designer.  This  approach  was  in  line  with  the  adaptive 
design  approach  of  quick  iterations  of  the  four  design 
stages. 

Staged  development  of  a  DSS  allows  for  changes  in 
the  DSS  to  be  identified  and  included  in  subsequent 
iterations  of  the  DSS.  To  facilitate  building  the  DSS  and 
making  it  easily  adapted  a  DSS  generator  had  to  be 
selected.  The  generator  selected  had  to  be  able  to  handle 
the  three  components  of  the  DSS. 

Components  of  a  DSS.  The  three  components  of 
a  DSS  are  the  data  base,  the  model  base,  and  the  man- 
machine  interface  (26:29).  The  data  base  component 
consists  of  the  data  and  the  data  base  software  to  manage 
the  data.  The  model  base  is  the  model  or  models  in  the  DSS 
and  the  software  to  run  those  models.  These  models  can  be 
analytical,  simulation,  or  any  model  that  manipulates  the 
data  bases  and  provides  the  user  with  information.  The 
man-machine  Interface  is  the  dialog  component  of  the  DSS. 

As  Sprague  and  Carlson  point  out,  "from  the  DSS  users' 
point  of  view  the  Dialog  is  the  System  (26:29)."  For  a 
DSS  to  work  correctly  the  generator  selected  must  be  able 
to  coordinate  the  three  components  in  a  manner  that  is 
relatively  transparent  to  the  user. 

In  the  development  of  this  DSS  the  model  base  was  the 
linear  programming  model  that  had  been  previously 
developed.  The  data  base  for  this  DSS  consists  of  the 
parameters  that  are  inputs  to  the  model.  The  man-machine 


interface  is  very  DSS  generator  specific  and  this  led  to  a 

search  ss  to  what  software  packages  were  available  for  the 
micros  at  AFIT.  In  order  to  run  the  linear  programming 
model  on  the  Zenith  248  micr ocomputers  it  was  discovered 
that  the  only  software  initially  available  was  LP83  from 
Sunset  Software  a  "professional  Linear  Programing  Package 
(27)."  A  DSS  generator  had  to  be  found  that  was  compatible 
with  LP83. 

Lotus  123  was  picked  as  the  DSS  generator  because:  1) 
it  was  availlable  at  AFIT,  2)  it  was  identified  as  being 
compatible  with  LP83  and  3)  it  seems  to  be  the  industry 
standard  for  spreadsheet  packages  and  many  users  are 
familiar  with  basic  operation  of  Lotus. 

During  the  process  of  building  the  DSS  and  validating 
the  spreadsheet  it  was  found  that  LP83  could  not  solve 
this  linear  programming  formulation.  A  newer  version  of 
Sunset  Software's  linear  programming  software  called  XA  was 
acquired  and  did  work  with  the  spreadsheet  (27:4.0-4.51). 

XA  was  used  for  the  remainder  of  this  research. 

Implementation  Phase.  The  implementation  phase  is  the 
last  phase  in  the  adaptive  design  approach  to  creating  a 
DSS.  Basically,  implementation  is  when  the  user  is  given 
the  DSS  to  use  and  to  critique.  Hopefully  the  user  is 
enthusiastic  about  acquiring  the  DSS  since  he  or  she  was 
involved  in  the  earlier  phases.  The  DSS  developed  in 
this  thesis  has  been  delivered  to  the  Analysis  Group  at 
HQ  MAC  and  the  recommendations  made  for  the  next  iteration 


of  the  DSS  are  discussed  in  chapter  VI. 


Summary 

This  chapter  has  described  the  methodologies  used  in 
the  creation  of  a  DSS.  The  chapter  began 

with  a  discussion  of  why  a  DSS  was  developed  followed  by  a 
description  of  what  a  DSS  is  and  the  techniques  used  to 
build  one.  The  three  components  of  a  DSS,  the  data  base, 
the  model  base,  and  the  man-machine  interface  were 
introduced.  The  next  three  chapters  will  describe  each  of 
these  components  for  the  current  DSS  developed. 


III.  Scenario  and  Data-Base  Development 
Introduction 

This  chapter  begins  with  a  discussion  of  the  scenario 
which  this  DSS  supports.  This  generic  scenario  and  the 
assumptions  and  limitations  on  the  various  players  in  the 
model  are  discussed  first. 

The  Far  Eastern  theater  scenario  used  for  this  DSS  is 
discussed  after  the  generic  scenario.  Next,  an 
introduction  to  the  data  base  required  in  this  scenario  and 
an  explanation  of  the  data  base  tables  is  presented.  This 
data  base  is  used  by  the  DSS  to  input  the  parameters  to  the 
mathematical  programming  model.  Each  table  is  presented  in 
its  storyboard  (screen  display)  form  with  explanations  of 
where  the  data  originated.  There  are  thirteen  tables  in  all 

Scenario 

The  scenario  presentation  is  developed  in  four  parts. 
The  first  discussion  is  about  the  locations  involved  in  the 
deployment  and  how  the  men  and  equipment  can  be  deployed  to 
these  locations.  The  second  part  of  the  scenario  involves 
the  assumptions  about  the  aircraft  used  in  this  DSS.  Part 
three  discusses  limitations  presented  by  airfields  in  this 
scenario.  The  last  part  presents  limitations  on  the  units 
to  be  deployed  in  the  scenario.  The  explanations  of  how 
these  assumptions  and  limitations  affect  the  mathematical 
formulation  are  covered  in  the  next  chapter,  the  model  base 
chapter . 


Deployment  Assumptions .  This  DSS  supports  a 
deployment  from  one  location  in  the  US  to  one  aerial 
port  of  debarkation  (APOD)  with  subsequent  movement  to  a 
forward  operating  location  (FOL).  In  this  context  the  APOD 
is  considered  to  be  in  the  theater  of  operations  but  near 
the  rear  areas  of  the  troops,  the  FOL  is  considered  in  the 
theater  but  nearer  to  the  front  edge  of  the  troops.  Direct 
delivery  of  troops  and  equipment  to  the  FOL  is  also 
possible  for  certain  aircraft.  The  deployment  to  the  APOD 
is  by  airland  missions  only.  Deployment  from  the  US  to  the 
FOL  is  by  either  airland  or  airdrop  and  the  model  decides 
the  proper  mix  to  optimize  combat  power  delivered  to  the 
objective  area.  Deployment  from  the  APOD  to  the  FOL  is 
accomplished  by  any  of  three  methods,  either  by  airland  or 
by  the  troops  moving  to  the  front  on  their  own  power  or  by 
equipment  being  moved  by  deployed  truck  units.  Again  the 
model  decides  the  proper  mixes  of  movements  to  optimize 
combat  power  delivered. 

The  timeframe  of  the  deployment  is  also  an  assumption 
of  this  DSS.  This  DSS  assumes  that  the  first  twenty  days 
of  a  deployment  are  the  most  critical  as  far  as  airlift  is 
concerned.  After  that  time  sealift  can  pick  up  most  of  the 
lift  requirements.  It  also  assumes  that  the  twenty  days  ca 
be  modeled  by  linking  four  five-day  periods  (14:70). 

Aircraft  Assumptions .  In  this  scenario  different 
aircraft  have  the  capability  to  accomplish  different 
missions.  These  missions  are:  intertheat.er  airland  -  US  to 


APOD,  intertheater  airland  direct  to  the  front 


ft 
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APOD,  intertheater  airland  direct  to  the  front  -  US  to  FOL, 

intertheater  airdrop  direct  to  the  front  -  us  to  FOL,  and 
intratheater  airland  -  APOD  to  FOL.  There  are  six 
different  types  of  aircraft  used  for  the  deployment  in  this 
scenario.  Three  of  these  aircraft:  C-5,  C-747,  and  DC8  are 
only  considered  capable  of  intertheater  airland  at  the 
APOD.  The  C-17  and  the  C-141  are  capable  of  all  four  types 
of  missions  and  the  C-130  can  only  fly  intratheater  -  APOD  to 
FOL  missions.  Individual  aircraft  and  their 
characteristics  can  be  changed  but  the  mission  capabilities 
are  fixed  due  to  the  formulation  of  the  linear  programming 
model.  For  example,  if  the  C-130  capabilities  were 
replaced  with  the  capabilities  of  a  different  aircraft  this 
DSS  would  still  assume  the  new  aircraft  was  only  capable  of 
intratheater  airlift.  If  the  mission  capabilities  had  to 
be  changed,  then  the  mathematical  formulation  would  have  to 
be  changed . 

Attrition  can  be  set  by  aircraft  and  by  mission  type 
and  is  expressed  as  percent  of  missions  flown  that  are 
expected  to  be  lost. 

Airfield  Assumptions .  There  are  two  major  limitations 
of  the  airfields  included  in  this  DSS.  The  first 
limitation  has  to  do  with  parking  aircraft  at  both  the  APOD 
and  the  FOL.  The  maximum  number  of  each  type  of  aircraft 
that  can  be  parked  at  each  airfield  is  input  to  the  DSS  and 
the  model  keeps  track  of  parking  space  used  up  and 
restricts  parking  to  what  is  available.  The  second 
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airfield  limitation  is  with  the  material  handling  equipment 
(MHE)  available  at  the  APOD  and  FOL.  These  limitations  are 
input  as  number  of  standard  pallets  of  cargo  capability  per 
day  at  the  APOD  and  the  FOL. 

Another  limitation  implicit  in  this  DSS  is  that  all 
aircraft  sorties  are  spaced  evenly  throughout  each  period. 
Sortie  generation,  parking  restrictions,  MHE  restrictions 
and  the  like  are  based  on  evenly  spaced  flows  of  aircraft. 

Unit  Assumptions .  There  are  eight  different  units 
considered  for  deployment  in  this  DSS.  They  are:  82nd 
Airborne,  82nd  HQ  Unit,  Artillery,  Mechanized,  Air  Assault, 
F-16,  Transportation  and  ALCE  units. 

The  first  assumption  regarding  deployable  units  is 
that  certain  units  are  to  be  deployed  only  to  certain 
areas.  The  HQ,  Transportation,  and  F-16  units  are 
delivered  only  to  the  APOD.  These  three  types  of  units 
work  out  of  the  APOD.  The  F-16  units  are  the  only  units 
whose  combat  power  is  counted  while  at  the  APOD;  because, 
they  fly  their  missions  out  of  the  APOD.  The  Airborne, 
Artillery,  Mechanized  and  Air  Assault  units  must  make  it  to 
the  front  before  any  portion  of  their  combat  power  is 
counted.  The  Transportat ion,  and  ALCE  units  are  not  given 
any  values  for  the  three  measures  of  combat  power; 
although,  the  deployment  of  Transportation  and  ALCE  units 
allows  greater  delivery  of  other  units.  The  DSS  decides  If 
the  cost,  in  airlift  requirements,  to  move  Tr anspor tat i on 
and  ALCE  units  is  worth  the  gain  in  delivery  capability. 


The  HQ  units  are  not  given  combat  power  values,  but  they 
are  required  with  the  delivery  of  Airborne  units. 

The  Airborne  and  Mechanized  are  considered  combat 
units  and  the  Artillery  and  Air  Assault  are  considered 
combat  support.  The  DSS  requires  there  to  be  at  least  as 
many  combat  units  as  there  are  combat  support  units 
delivered  to  the  FOL. 

This  DSS  can  support  any  scenario  that  fits  within  the 
assumptions  listed  above.  Different  scenarios  are 
developed  by  changing  the  parameter  inputs  to  the  DSS. 

This  thesis  has  developed  one  scenario  built  around  a  Far 
Eastern  theater  of  operations. 

Far  Eastern  Theater  Scenario 

The  Far  Eastern  theater  scenario  and  data  base 
required  for  this  scenario  is  discussed  in  this  section. 

The  scenario  assumptions  are  presented  first  followed  by  an 
introduction  of  the  data  base  tables. 

Scenario  Assumptions.  The  scenario  in  this  DSS  is 
based  on  the  following  assumptions: 

1)  All  intertheater  aircraft  will  use  Travis  AFB  as 
the  staging  base  for  departure  from  the  CONUS. 

2)  The  APOD  is  Kwangju  AFB  Korea  and  the  FOL  is 
Suwon  AFB  Korea, 

3)  The  available  units  to  deploy  are  assumed  to  be 
at  Travis  AFB  and  ready  to  upload. 

4)  All  bases  are  operational  24  hours  a  dtay. 


These  are  the  basic  assumptions  of  this  scenario  other 
assumptions  are  presented  as  the  data  base  tables  are  described 

Data  Base  Tables  and  Assumptions .  There  are  thirteen 
data  base  tables.  These  tables  are  grouped  in  a  logical 
fashion  to  help  the  user  remember  where  certain  parameters 
are  in  the  data  base. 

In  all  of  the  thirteen  tables  a  column  contains 
different  data  values  of  a  data  type.  For  example,  bulk 
cargo  carrying  capability  would  be  one  column  and  in  that 
column  would  be  the  different  values  of  that  parameter  for 
the  different  aircraft  in  the  scenario.  The  rows  in  the 
tables  contain  different  parameter  values  for  different 
aircraft,  units,  or  airfields. 

The  name  given  for  each  parameter  in  the  data  base  is 
the  Lotus  1-2-3  range  name  used  to  generate  the  matrix  for 
the  mathematical  formulation.  The  capital  letters  are  the 
range  names,  the  lower  case  letters  a,  j,  and  z,  when  used 
as  part  of  the  range  name,  refer  to  the  cor respo’ ■* '  ~>q 
letters  at  the  top  of  the  columns.  For  example,  hi*  range 
name  for  the  parameter  for  the  intertheater  utilization 
rates  for  the  C-5  is  aC5z,  where  the  a  and  z  come  from  the 
top  of  the  column  and  a  =UTE  and  z  =  AP,  thus  the  range  name 
is  UTEC5AP.  These  range  names  become  important  only  when 
decoding  or  changing  the  mathematical  formulation. 

There  are  four  major  groupings  of  tables;  these 
groupings  are:  aircraft,  airfields,  units,  and 
requirements.  In  the  following  sections,  each  group  is 


presented  along  explanations  of  where  the  data  originated 
and  the  assumptions  underlying  the  data. 


The  data  base  tables  are  presented  in  the  same  form  as 
the  CRT  display  in  the  DSS;  therefore,  the  reminders  as  to 
which  commands  take  the  user  to  which  menus  are  also  in  the 
tables . 

Aircraft  Data  Base.  There  are  five  different 
screen  displays  for  the  aircraft  parameter  portion  of  the 
data  base.  These  five  screen  displays  are  the  aircraft 
available,  usage  rates,  performance  capabilities,  cargo 
capabilities  and  attrition  displays.  The  aircraft 
available  screen  display  is  shown  in  Table  I. 


Table  I 


AIRCRAFT  AVAILABLE 


lumbar  Description 

MUMC 5 1  40  C5A/B  aircraft  availiable,  60th  MAW,  Travis  AFB 

MUM?  17 1  40  C17  aircraft  used  in  this  run  of  the  model 

MUM?  1411  110  C141's  from  the  meat  coast,  62nd,  60th,  63rd 

MUM7471  30  CRAF  747 s 

MUMDC81  20  CRAF  DC8s 

MUMC1301  60  C130s  used  in  this  run  of  the  model 


MUMTAC 


18  Number  of  fighters  assigned  to  each  fighter  unit 


alt  a  for  menu  to  change  more  aircraft  data 

alt  c  for  change  menu 

alt  m  to  return  to  main  menu 

alt  p  use  to  print,  highlight  with  arrow  keys  press  return. 


The  numbers  of  the  various  types  of  operational 
transport,  C-5,  C-141,  and  C-130,  aircraft  available 
for  this  deployment  were  assumed  to  be  the  numbers  of  the 


various  aircraft  available  to  22nd  Air  Force.  22nd  Air 


Force  is  responsible  for  airlift  in  the  Far  Eastern  part  of 
the  world.  The  number  of  C-17  and  Civil  Reserve  Air  Fleet 
C-747  and  DC 8  used  in  this  table  were  set  as  possible 
numbers  for  this  scenario. 

Table  II  contains  the  aircraft  usage  rates  used  in 
this  DSS.  The  usage  rate  is  the  days  required  for  an 
aircraft  to  complete  a  complete  round  trip  of  a  particular 
miss i on . 


Table  II 


AIRCRAFT 

OSAGE  RATES 

Maae 

Inter 

lntra  Description 

j=er 

j=ra  Days  required  for  round  trip  aission 

IMTJC5 

2.2 

N/A  C5A/B  days  required 

IMTjC17 

2 

0.2  C17  days  required 

IMTjC141 

2.1 

0  C141  days  required 

IMTJ747 

2 

M/A  CRAF  747  days  required 

IMTjDCS 

2 

M/A  CRAF  DCS  days  required 

IMTJC130 

N/A 

0.25  Cl 30  days  required 

alt  a 

for  aenu 

to  change  aore  aircraft  data 

alt  c 

for  change  aenu 

alt  a 

to  return 

to  aaln  aenu 

alt  p 

use  to  print,  highlight  with  arrow  keys  press  return. 

The  usage  rates  for  each  aircraft  must  be  figured 
using  average  ground  speeds  and  the  lengths  of  various 
mission  legs  in  the  deployment  scenario.  For  this  scenario 
the  aircraft  departing  Travis  AFB  would  make  an  enroute 
stop  at  Elmendorf  AFB  for  fuel  and  continue  on  to  either 
the  APOD  or  the  FOL.  After  offloading  the  mission  would 


continue  on  to  Yokota  AFB  £or  refuel  and  crew  change  and 
then  proceed  back  to  Travis  again  through  Elmendorf. 
Standard  ground  times  and  expected  maintenance  delay  times 
are  included  to  give  a  total  expected  round  trip  time  for 
each  aircraft  (14:72). 

Table  three  contains  the  parameters  for  the  aircraft 
performance  capabilities. 


Table  III 
AIRCRAFT  CAPABILITIES 


Maas  --Dti 1 ization  Rates  a=UTE  (hr^/day)-  True  Ground  Ground 

-  Intertheater  -  Intra  Airdrop  Airspeed  Times  Times 

to  APOD  to  FOL  (knots)  (hours)  at  FOL 

z=AP  z=FO  z=IM  z=AD  a=SPD  a=GTM  a=GTMF 


aC5z 

12.5 

N/A 

M/A 

M/A 

423 

3.25 

M/A 

aC17x 

15.65 

15.65 

8. 1 

15.2 

440 

2 

1.75 

aC141z 

12.5 

10 

10 

8 

410 

2.25 

2 

*747* 

10 

M/A 

M/A 

M/A 

450 

3.6 

N/A 

aDC8z 

10 

M/A 

M/A 

M/A 

440 

2.8 

M/A 

aC130z 

M/A 

M/A 

4 

M/A 

270 

2.25 

1.5 

alt  a  (or  menu  to  change  more  aircraft  data 

alt  c  for  change  menu 

alt  a  to  return  to  aain  aenu 

alt  p  use  to  print,  highlight  with  arrow  keys  press  return. 


The  data  for  the  utilization  rates  and  airspeeds  used 
in  this  scenario  was  extracted  from  the  US  Air  Force 
Airlift  Master  Plan  ( 9 : A— 10).  The  ground  times  for  both 
the  APOD  and  FOL  are  typical  ground  times  (14:79). 

Table  IV  provides  the  parameters  that  pertain  to  the 
aircraft  cargo  capabilities.  This  table  includes,  for  each 
aircraft,  how  much  of  what  type  of  cargo  can  be  carried. 


how  many  standard  pallets  can  be  carried,  and  the  ease  of 


offload  factor  that  converts  different  types  of  cargo  to 
equivalent  number  of  pallets  of  offload  capability  required 


Table  IV 

AIRCRAFT  CARGO  CAPABILITIES  AND  EASE  OF  OFFLOAD 


Name 


Outsize 

Oversize 

Bulk 

PersonnelMax  Pallets  - 

(tons) 

(tons) 

( tons) 

(people) 

Airland 

Airdrop 

z=0UT 

z=0VR 

z  =  BLK 

z  =  PER 

a?  MHE 

no 

a=ADC 

aC5z 

73.4 

78.  1 

82.8 

340 

36 

N/A 

aC17z 

45 

48 

50 

102 

18 

10 

aC  1 4 1  z 

N/A 

20 

23 

152 

13 

8 

a747z 

N/A 

59.2 

99.  i 

0 

36 

N/A 

aDC8z 

N/A 

N/A 

41.4 

219 

0 

N/A 

aC 130z 

N/A 

N/A 

13.2 

64 

6 

N/A 

Ease  of  offload  standardizing  factor 

•  a=EAS 

aC5z 

0.05 

0.2 

1 

0.05 

aC  17z 

0.05 

0.2 

1 

0.05 

alt  a 

for  aircraft  menu 

aC14  lz 

0.05 

0.2 

1 

0.05 

alt  c 

for  change  menu 

a747z 

0.05 

0.2 

1 

0.05 

alt  m 

to  return  to  main 

aDC8z 

0.05 

0.2 

1 

0.05 

alt  p 

use  to  print 

aC130z 

0.05 

0.2 

1 

0.05 

The  data  for  the  cargo  capabilities  of  the  C-5  (7:9), 
C-141  (7:13) ,C-747  (7:20),  DC-8  (7:20),  and  C-130  (7:A4-8) 
were  extracted  from  Air  Force  Regulation  76-2  and  are  the 
average  tons  carried  per  aircraft.  The  number  of  pallets 
per  aircraft  was  also  extracted  from  AFR  76-2  (7:A4-10). 

The  Cl 7  numbers  were  not  published  but  were  obtained  from 
an  interview  with  the  chief  C-17  loadmaster  at  HQ  MAC  (19). 

A  value  of  one  for  the  ease  of  offload  standardizing 
factors  of  table  IV  indicates  that  enough  material  handling 
equipment  (MHE)  must  be  available  to  offload  the  maximum 
number  of  standard  pallets  that  the  aircraft  can  carry. 

For  outsized  cargo  which  is  considered  to  be  100%  rolling 
stock,  such  as  trucks  and  tanks,  only  minimal  MHE  is 


» 


required  to  offload,  thus  the  .05  factor  for  outsize  cargo, 
oversize  cargo  is  considered  to  be  80%  rolling  stock  thus 
the  .2  for  standardization  factor  under  the  oversize 
column.  Bulk  is  considered  completely  palletized  and  gets 
a  one  for  its  factor.  And  lastly,  personnel  which  can  walk 
off  the  aircraft  on  their  own  but  require  their  baggage  to 
be  removed  the  aircraft  receive  a  factor  of  .1  (12). 

The  last  table  of  aircraft  parameters.  Table  V, 
contains  the  attrition  values  used  in  this  DSS. 

Table  V 

ATTRITION 


Name  -  Mission  Type  - 


to  APOD 

to  FOL 

Intra 

Airdrop 

z  =  AP 

z=F0 

z*IN 

z  =  AD 

Attrition 

Rate 

a=  ATRT 

aC5z 

0.001 

N/A 

N/A 

N/A 

aC17z 

0.0005 

0.0025 

0.005 

0.005 

aC 1 4 1  z 

0.0015 

0.005 

0.01 

0.01 

a747z 

0.001 

N/A 

N/A 

N/A 

aDC8z 

0.001 

N/A 

N/A 

N/A 

aC130z 

W/A 

N/A 

0.005 

N/A 

alt  a  for  menu  to  change  more  aircraft  data 

alt  c  for  change  menu 

alt  m  to  return  to  main  menu 

alt  p  use  to  print,  highlight  with  arrow  keys  press  return. 


The  attrition  rates  were  based  upon  a  discussion  with  Maj 
william  Ewing  of  HQ  MAC/AG  (10).  He  has  studied  attrition 
and  has  published  a  paper  on  survivability  enhancements  to 
the  airlift  fleet  (11).  While  his  study  shows  many 
factors  go  into  attrition  rates,  Maj  Ewing  felt  that  the 
rates  in  the  table  were  representative  of  rates  that  could 


♦.t**  IV 


be  expected  in  this  scenario. 

Airfield  Data  Base.  The  airfield  data  base 
group  of  tables  contains  three  screen  displays.  These 
three  screens  are:  airfield  distance,  airfield  ramp 
capacity,  and  material  handling  equipment.  Table  VI 
contains  the  distance  table. 

Table  VI 

DISTANCE  TABLE 

Name  Distance 

(nautical ) 

(miles) 

DISAPFO  200  Distance  from  the  APOD  to  the  FOL 

DISUSAP  4440  Distance  from  the  US  to  the  APOD 

DISUSFO  4640  Distance  from  the  US  to  the  FOL 

alt  f  for  airfield  change  menu 

alt  c  for  change  menu 

alt  m  to  return  to  main  menu 

alt  p  use  to  print,  highlight  with  arrow  keys  press  return. 

The  distances  in  Table  VI  are  approximate  and  are 
taken  from  the  Airlift  Planning  Guide  (15:38). 

Table  VI  r  contains  the  airfield  ramp  capacity 
parameters.  The  numbers  in  the  table  were  obtained  from 
the  HQ  MAC  Maximum  on  the  Ground  (MOG)  listing  (21) 

The  last  table  in  the  airfield  group.  Table  VIII  is 
the  material  handling  equipment  table.  The  data  on  this 
table  are  the  number  of  pallet  equivalents  per  day  of  cargo 
capacity  assumed  to  be  at  the  APOD  and  FOL. 
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Table  VII 


AIRFIELD  RAMP  CAPACITIES 


Name  Location 

Kwangju  Suwon 

Airfield  RKJJ  RKSO 

Identifier  (APOD)  (FOL) 

a-NPRKA  a=NPKF 


aCS  8  3 

aC  17  15  14 

aC 14 1  12  12 

a747  8  3 

aDC8  12  12 

aC 130  15  14 

aF16  40  N/A 


alt  f  for  airfield  change  menu 

alt  c  for  change  menu 

alt  m  to  return  to  main  menu 

alt  p  use  to  print,  highlight  with  arrow  keys  press  return. 


Table  VIII 

MATERIAL  HANDLING  EQUIPMENT 

Name  -  Pallet  Equivalents  /  day  - Comments 


MHEAPOD  1000 
MHEFOL  500 
MHEALCE  500 


at  the  APOD 
at  the  FOL 
ALCE  addition 


alt  f  for  airfield  change  menu 

ait  c  for  change  menu 

alt  m  to  return  to  main  menu 

alt  p  use  to  print,  highlight  with  arrow  keys  press  return. 

Units  Data  Base.  This  unit  data  base  group  of 
tables  includes  three  tables.  These  three  tables  are  the 
deploying  unit  requirements  table,  the  deploying  unit 
capabilities  table,  and  the  unit  indicators  and  combat 
value  table. 
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The  first  unit  data  base  table.  Table  IX,  contains  the 


parameters  for  the  airlift  requirements  to  move  the 
different  deployable  units  in  the  scenario.  These 
requirements  are  given  in  tons  of  outsize,  oversize,  and 
bulk  cargo  and  numbers  of  people. 


Table  IX 

DEPLOYING  UNIT  REQUIREMENTS 


Name 


Number  -  Cargo 

Available -  a  = 

a=UNIT  outsize  oversize 
no  z  z^OUT  z=OVR 


type  -  Daily 

TON  Supply 

bulk  personnel Consumed 

z=BLK  z=PER  a=TONC  no  z 


aAB82z 

9 

0 

197.3 

54.9 

697 

32.76248 

aHQ82z 

3 

0 

81.8 

15.  1 

101 

4.747505 

aAASSz 

4 

122 

523.  1 

54.1 

277 

13.02038 

aARTz 

3 

41.4 

361.1 

44.8 

188 

8.83694 

aMECHz 

5 

3770.3 

1237.7 

108.6 

543 

25.52371 

aF  16z 

1 

0 

188 

85.4 

423 

19.88311 

aTRKz 

3 

0 

1504.7 

189.  1 

472 

22. 18636 

aALCEz 

2 

0 

100 

40 

150 

7.05075 

alt  u 

for  menu  for  unit 

changes 

alt  c 

for  change 

menu 

alt  m 

to  return 

to  main 

menu 

alt  p 

use  to  print,  highlight  with 

arrow  keys 

press 

return . 

The  data  in  Table  IX  for  the  deployable  army  units  are 
taken  from  the  MAC  pamphlet  50-13,  the  Airlift  Planning 
Guide.  The  82nd  Airborne  units  to  be  deployed  were  the 
infantry  battalion  of  the  Airborne  Division  (15:8).  The 
HQ  units  were  the  Headquarters  and  Headquarters  Company  of 
the  Airborne  Division  (15:8).  The  Air  Assault  units  were 
the  Attack  Helicopter  Battalions  of  the  Air  Assault 
Division  (15:6).  The  Artillery  units  were  the  Division 
Artillery  of  the  Mechanized  Division  (15:12).  The 
Mechanized  units  were  the  Tank  Battalions  of  the  Mechanized 
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Division  (15:12).  Lastly,  the  Transportation  units  were 
the  Supply  and  Transportation  Battalions  of  the  Airborne 
Division  (15:8).  The  data  for  the  F-16  units  including  the 
supply  consumption  was  determined  from  a  discussion  with 
Capt  Golden  of  Hq  MAC  (13).  The  data  for  the  ALCE  and 
its  supply  consumption  was  determined  to  be  representative 
of  a  typical  ALCE  that  might  be  deployed  in  this  scenario 
and  was  obtained  through  a  discussion  with  Chief  Burkhardt 
O  f  HQ  MAC  ( 4 ) . 

The  second  table  in  this  group.  Table  X,  is  the 
Deploying  Unit  Capabilities  screen  display.  The  first 
three  columns  of  this  table  show  the  units  inherent  combat 
power  values  for  the  three  measures  of  combat  power: 
firepower,  anti-tank  capability,  and  front  line  trace. 


V.  J 


Table  X 

DEPLOYING  UNITS  CAPABILITIES 


Name 


aAB82 
aHQ82 
aAASS 
aABT 
aMECH 
aF  16 
aTRX 
a  ALCE 
al t  u 
alt  c 
alt  m 
alt  p 


Measures  of  Ef f ectivenessTransportDistance  Periods 

-  to  the  Unit  Can  APOD  to  FOL 

Fire  Anti-TankDefensive  Front  Travel  inDISAPFO/TVLz 
Power  Strength  Frontage  Capabilit  one  day  /PL 
a=FP  a  =  AT  a=FLT  a-TMC  a=TVL  a  =  PTVL 


4 

0 

6 

3 

8 

8 

0 

0 


19.5 
0 

28.5 
3 

40 

38 

0 

0 


4 

0 

4 

0 

6 

0 

0 

0 


0 

0 

0 

0 

0 

0 

182 

0 


20 

20 

18 


4 

4 


4.444444 

12  8.666666 
14  5.714285 
ERR 
2 

ERR 


0 

40 

0 


for  menu  for  unit  changes 
for  change  menu 
to  return  to  main  menu 


use  to  print,  highlight  with  arrow  keys  press  return. 
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The  numbers  for  the  three  combat  power  values  were 
taken  from  Cooke.  His  data  for  front  line  trace  came  from 
Army  doctrinal  publications;  and  the  data  for  anti-tank  was 
figured  by  counting  the  TOW  and  DRAGON  anti-tank  systems 
the  units  owned,  assigning  a  value  of  one  for  each  TOW  and 
.5  for  each  DRAGON.  The  combat  firepower  values  were 
determined  from  relative  firepower  scores  of  the  units  as 
used  in  an  Army  War  College  f or ce -on- f or ce  war  game  (6:81). 

The  ton-mile  lift  capability  of  the  Transportation  unit 
is  in  the  next  column  and  to  its  right  the  distance  each 
unit  can  travel  in  a  day  is  given.  The  periods  it  takes  a 
unit  to  travel  from  the  APOD  to  the  FOL  is  in  the  last 
column  and  is  figured  automatically  when  the  distance  from 
APOD  to  FOL  and  the  distance  a  unit  can  travel  in  a  day  are 
set . 

The  next  table  in  this  group  of  screen  displays.  Table 
XI,  contain  the  values  for  combat  value  over  time.  The  DSS 
uses  Lotus  123  as  the  DSS  generator,  and  due  to  the  size 
limitations  of  the  Lotus  spreadsheet  when  used  with  MS  DOS 
the  DSS  had  to  split  into  two  spreadsheets.  Some  of  the 
constraint  equations  had  to  be  placed  on  the  second 
spreadsheet  and  this  table  includes  reminders  to  the  user 
to  make  changes  for  rigger  capacity,  and  the  combat  and 
airdrop  indicators  on  the  other  spreadsheet. 

The  combat  value  over  time  multipliers  emphasize  the 
fact  that  firepower  delivered  early  is  worth  more  than 
firepower  delivered  later.  The  values  used  for  CPI  in 


Table  XI  were  taken  from  the  work  of  Cooke  (6:83). 


COMBAT  VALUE  OVER  TIME 


Table  XI 

INDICATORS 


Name 


cpii 

CPI2 

CPI3 

CPU 


Period 


1 

2 

3 

4 


Value 

factor 

2.5 

1.8 
1.3 
1 .  1 


Name  Airdrop  Combat  Ind 

Indicator  1  combat 

l  =  yes  -1  support 

0=no  0  neither 

a=AD  «*  NOTE  *  a=CI 


aAB32  1 

aHQ82  1 

aAASS  0 

aART  0 

aMECH  0 

aF16  0 

aTRK  0 

aALCE  0 

menu  for  unit  changes 
for  change  menu 
to  return  to  main  menu 

use  to  print,  highlight  with  arrow  keys  press  return 


RIGGER  O  PACITY 
RC  *«  NOTE  «* 

Must  o.  changed  on  part  B 
spreadsheet 


alt  u 
alt  c 
alt  m 
alt  p 


Must  be  changed 
on  part  B 
spreadsheet 


The  last  table  In  this  group  Is  Table  XII.  This  table 
is  on  the  output  spreadsheet. 


Table  XII 

COMBAT  VALUE  OVER  TIME.  RIGGER  CAPACITY.  AND  UNIT  INDICATORS 


AIRDROP  CAPACITY 

IN  PALLETS 

NAME  a=AD 

aC  17  10 

aC141  8 

Name 

DEPLOYED  UNIT  INDICATORS 
Airdrop  Combat 

l  =  yes 

0  =  no 
a  =  AD 

1 

-1 

0 

combat 
support 
ne  l  ther 
a=CI 

aAB82 

1 

1 

RIGGER 

CAPACITY 

aHQ02 

1 

-1 

IN  PALLETS 

aAASS 

0 

1 

RC 

250 

aART 

0 

-1 

PERIOD 

LENGTH 

aMECH 

0 

1 

PL 

5 

aF  16 

0 

0 

aTRK 

0 

0 

aALCE 

0 

0 

alt  m 

for  main  menu 

alt  o 

for  output 

menu 

alt  g 

for  graph 

menu 

This  table  contains  the  maximum  number  of  pallets  that 
the  two  aircraft  capable  of  airdrop  can  carry  in  the 
airdrop  configuration  (14:79). 

This  table  also  includes  the  parameter  for  the  maximum 
number  of  pallets  per  day  the  army  airdrop  pallet  riggers 
can  rig.  The  number  used  here  was  a  set  as  one  possible 
representative  number  of  rigger  capabi 1  it ies . 

The  airdrop  indicators  were  set  so  that  only  the 
Airborne  Infantry  Battalions  and  the  82nd  Airborne 
Headquarters  could  be  airdropped.  The  combat/combat 
support  indicators  were  set  so  that  the  82nd  HQ  and 
Artillery  Battalions  would  be  considered  combat  support 
while  the  Airborne  Infintry  Battalion,  Attack  Helicopter 
Battalion,  and  Mechanized  Tank  Battalion  were  considered 
combat.  The  F-16,  Transportation,  and  ALCE  were  considered 
neither  combat  nor  combat  support  as  none  of  these  units 
are  delivered  past  the  APOD.  These  indicator  values  were 
taken  from  Tate  (28:A-6). 

Requirements  Data  Base.  The  last  data  base 
table.  Table  XIII,  is  the  requirements  screen  display. 

The  top  of  this  table  contains  the  parameters  for  the 
minimum  requirements  of  anti-tank  and  front  line  trace 
capability  needed  in  each  period.  The  values  used  in 
this  DSS  are  representat 1  /e  values,  the  actual  values  used 
in  a  study  would  have  to  be  set  by  experts  familiar  with 
the  battle  scenario. 


Table  XIII 


REQUIREMENT  PARAMETERS 


Name 

Periods 
one  z=l 

two  z  =  2  three 

z- 

3four  z=4 

GATz 

25 

35 

45 

55 

GFLTz 

5 

10 

15 

20 

GCPz 

Note : 

Combat  power  is 

the 

Objective  so  is  not  a  goal 

L 

4 

Number  of  periods 

in  this  model,  FIXED  AT  4 

PL 

5 

Period  length 

in 

days  used  in  this  model 

CONSUMPTION 

AT  APOD 

AND  FOL 

al  t  r 

for  menu  to  change  Requirements 

START  OF 

DEPLOYMENT  alt  c 

for  change  menu 

— 

alt  m 

to  return  to  main  menu 

aAPOD 

200 

alt  p 

use  to  print,  highlight  with 

aFOL 

100 

arrow  keys  and  press  return. 

a=TONC 

TONS/DAY 

The  number  of  periods  is  fixed  at  four  by  the 
mathematical  formulation  and  to  change  It  from  four  would 
require  new  constraints  and  variables  to  be  added  to  the 
formulation.  The  period  length,  while  set  at  five  for  this 
DSS,  can  be  changed  and  required  adjustments  in  the 
formulation  would  be  made  automatically. 

The  predeployment  supply  consumption  rate  parameters 
at  the  APOD  and  the  FOL  are  the  last  of  the  requirements 
data.  The  values  used  in  this  DSS  are  representative 
values  and  the  exact  values  would  be  set  by  examining  the 
actual  scenario  under  study. 

Summary 

This  chapter  has  presented  the  first  component  of  the 


DSS,  the  data  base.  The  generic  scenario  was  presented 
first  followed  by  the  aircraft,  airfield,  units,  and 


requirements  data  base  tables.  The  generic  scenario  shows 
the  overall  scenario  that  this  DSS  supports  while  the  data 
base  tables  show  the  specific  scenario  developed  in  this 
presentation  of  the  DSS.  The  next  chapter  discusses  the 
model  base  component. 


IV.  Model  Development 
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Introduction 

In  this  chapter  the  linear  programing  model 
formulation  is  developed.  Capt  Cooke  did  the  original 
formulation  of  this  model.  The  model  has  evolved  through 
the  works  of  both  Capt  Tate  and  Maj  Haile.  Capt  Tate 
updated  some  of  the  parameter  names  to  make  the  model  more 
readable,  and  changed  some  of  the  formulations  to  conform 
to  the  computer  program  he  developed  (28:ch3-l).  Maj 
Haile  applied  the  model  using  a  Far  Eastern  scenario  with 
one  APOD  (aerial  port  of  debarkation)  and  one  FOL  (forward 
operating  location),  and  he  added  a  method  of  accounting 
for  attrition  in  the  airlift  fleet  (14:ix).  Haile 
borrowed  from  both  Cooke  and  Tate  and  again  changed  some 
of  the  formulations  and  parameters  used  (14:26). 

Model  Changes.  The  formulation  presented  in  this 
chapter  borrows  heavily  from  Haile's  formulation,  changes 
some  of  the  formulation,  adds  some  new  variables,  and 
defines  the  parameters,  some  with  new  names  to  make  the 
formulation  easier  to  follow.  Current  changes  to  Haile's 
formulation  are  mainly  in  the  way  attrition  is  handled  and 
in  the  way  the  resuppLy  constraints  are  formulated. 

Haile  had  subtracted  an  average  combat  power  per 
aircraft  from  the  objective  function  for  lost  missions  but 
still  allowed  the  aircraft  loads  to  be  delivered.  The 
current  formulation  uses  an  additional  set  of  attrition 
constraints  to  set  the  number  of  aircraft  available  for  a 
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period  which  is  based  on  the  number  of  missions  flown  and 
percentage  of  aircraft  lost  in  previous  periods.  Also, 
attrlt.ed  assets  are  subtracted  from  unit  deliveries  thus 
not  allowing  credit  for  lost  portions  of  a  unit  and 
subsequently  not  allowing  that  portion  of  combat  power  to 
be  applied. 

Many  changes  are  made  in  the  formulation  of  the 
resupply  constraints.  First,  previous  formulations  forced 
the  model  to  make  shipments  with  transportation  units 
while  the  current  formulation  allows  the  linear  program  to 
use  or  not  use  the  transportation  units.  To  accomplish 
this  a  new  set  of  variables  is  used  to  represent  the 
number  of  transportation  unit  deliveries  made  to  the  FOL 
in  each  period.  Also  included  in  the  formulation  is  a  new 
set  of  constraints  to  restrict  transportation  unit 
shipments  to  be  less  than  the  number  of  transpor tat i on 
units  avalliable  --  transportation  units  that  have  been 
delivered  In  previous  periods.  Second,  the  supply 
constraints  themselves  have  been  reformulated  to  make  use 
of  the  new  variable  for  truck  shipments.  Third,  a  new  set 
of  variables  for  aircraft  payloads  which  consist  of 
supplies  is  included  in  the  model.  Earlier  formulations 
by  Cooke  and  Tate  included  this  variable  but  the 
formulation  by  Haile  did  not.  Without  this  variable  it 
seemed  that  the  model  used  shipments  of  bulk  cargo  to 
satisfy  constraints  for  both  supplies  and  unit  bulk  cargo 
requirements.  Fourth,  the  capabilities  to  account  for 


supply  consumption  requirements  at  the  APOD  and  FOL  prior 
to  the  deployment  and  to  fulfill  those  requirements  during 
the  deployment  are  new  to  the  model.  Previous 
formulations  did  not  consider  the  possibility  of  supply 
requirements  due  to  units  permanently  stationed  at  the 
APOD  and  FOL  bases.  This  is  accomplished  with  the  new 
parameters  TONCAPOD  and  TONCFOL  (the  tons  of  consumption 
required  prior  to  the  deployment  at  the  APOD  and  FOL 
respectively)  as  the  right  hand  side  for  the  supply 
constra ints . 

The  last  two  changes  to  the  model  include  adding  a 
surplus  variable  for  rigged  airdrop  pallets  and  adding 
provisions  for  separate  ground  times  at  the  APOD  and  FOL 
for  each  type  of  aircraft.  The  variable  P ( 1 )  used  for 
excess  airdrop  pallets  rigged  in  a  period  was  identified 
by  Cooke.  Haile  used  the  same  variable  as  he  used  for  the 
excess  unit  bulk  cargo  shipments  and  it  seemed  there  was  a 
potential  to  double  count  cargo.  The  parameters  GTMA(i) 
and  GTMF(i)  (ground  time  for  aircraft  i  at  the  APOD  and 
FOL  respectively)  are  new.  Before  there  was  only  one 
ground  time  associated  with  each  type  ofaircraft. 

Scheduled  ground  times  could  be  different  at  the  APOD  and 
FOL  for  reasons  such  as  aircraft  refueling  only  at  the 
APOD  on  Intratheater  missions. 

Model  Size.  The  current  formulation  uses  338 
variables  and  180  constraints.  This  is  an  increase  of  50 
variables  and  12  constraints  compared  to  Haile's 


formulation.  The  size  of  this  formulation  does  tend  to 
grow  rapidly. 

The  variables  and  constraints  can  be  grouped  into 
period,  APOD,  and  FOL  related  sets.  By  using  the  number 
of  sets  of  variables  and  constraints  in  each  of  these 
groups  we  can  create  an  equation  to  give  a  rough  idea  of 
how  the  mathematical  formulation  would  grow  with  various 
add i t ions  . 

The  formulation  has  86  sets  of  period  specific 
variables  and  44  sets  of  period  specific  constraints.  For 
each  period  added  onto  the  current  formulation  86  new 
variables  and  44  new  constraints  would  be  required.  To 
expand  from  4  periods  to  30  one  day  periods  would  require, 
(26  X  86)  +  338  =  2574  total  variables 
and 

(26  X  44)  +  180  =  1324  total  constraints. 

The  formulation  has  204  variables  that  are  concerned 
with  delivery  to  the  APOD  of  intratheater  movements  from 
the  APOD.  The  formulation  also  has  44  constraints  that  are 
associated  with  the  APOD.  To  add  an  additional  APOD  would 
require  204  +  338  =  542  total  variables  and 

44  +  180  =  224  total  constraints. 

For  the  FOL  the  formulation  has  148  variables,  not 
counting  air  drop  related  variables,  and  28  constraints. 

One  additional  FOL  would  require  a  total  of  338  +  148  =  486 
variables  and  180  f  28  -  208  constraints. 

Making  multiple  changes  to  the  formulation  does  not 


just  cause  additive  increases  in  the  size  requirements. 

For  example,  changing  from  4  to  30  periods  and  from  one  to 
two  APODs  would  not  cause  the  number  of  variables  to 
increase  to  2574  +  44  =  2618.  The  increase  from  one 
to  two  APODs  does  at  first  cause  the  number  of  variables  to 
increase  by  44  but  it  also  increases  the  number  of  period 
specific  sets  of  variables  from  86  to  97.  When  the  number 
of  periods  are  increased  to  30  the  total  number  of 
variables  would  increase  to  338  +  44  +  (26  X  97)  =  2904. 
Similiar  changes  happen  in  the  number  of  constraints. 

Model  Attributes.  The  model  is  a  linear  program  that 
quantifies  the  value  of  the  combat  power  delivered  to  an 
objective  area,  not  in  terms  of  tons  of  cargo  delivered, 
but  in  terms  of  a  time  dependent  value  of  the  combat 
power  of  the  military  units  delivered.  Many  factors  go 
into  the  success  of  a  large  scale  deployment.  This  model 
captures  the  effects  of  the  following  factors: 

1.  The  three  measures  of  combat  power  for  military 
units:  anti-tank,  measured  in  TOW  (tube  launched 
optically  sighted  wire  guided  missle)  equivalents; 
defensive  frontage,  measured  in  kilometers  of  front 
line  trace  capability;  and  firepower  measured  in 
relative  firepower  capabilities. 

2.  The  type,  cargo  capabilities,  mission 

capab i 1 i t i es ,  and  numbers  of  the  aircraft  available 
for  the  deployment. 


3.  The  attrition  of  the  original  aircraft  as  the 
model  progresses  through  the  four,  five-day  periods. 
The  attrition  rate,  a  percent  of  missions  flown,  can 
be  set  for  individual  mission  and  aircraft  types. 

4.  The  utilization  rates  of  the  various  aircraft  in 
the  scenario. 

5.  The  parking  ramp  space  available  at  both  the  APOD 
and  the  FOL . 

6.  The  material  handling  equipment  ( MHE )  available 
at  both  the  APOD  and  the  FOL  and  the  increase  in 
capabilities  that  an  Air  Force  Airlift  Control 
Element  (ALCE)  provides. 

7.  The  number  of  units  to  be  deployed.  In  this  case 
there  are  eight  different  unit  types  and  various 
numbers  of  each  type. 

8.  The  different  requirements  of  each  type  of  unit 
for  the  four  different  kinds  of  aircraft  payloads 
considered  in  this  model,  specifically,  outsize 
cargo,  oversize  cargo,  bulk  cargo,  and  personnel. 
Portions  of  units  are  not  considered  delivered  until 
the  proper  ratios  of  aircraft  payloads  have  arrived. 

9.  The  supplies  required  to  sustain  the  deployed 
units. 

10.  Four  different  methods  of  delivery.  The  first 
and  second  are  shipments  of  units  directly  to  the  FOL 
either  by  airland  or  airdrop.  The  third  method  is 
shipment  to  the  APOD  which  either  remains  at  the  APOD 


or  moves  to  the  front  on  Its  own  power.  Lastly, 
shipment  to  the  APOD  with  subsequent  intratheater 
(APOD  to  FOL)  airlift. 

11.  A  linkage  between  the  combat  support  units  and 
the  combat  units  deployed  and  a  linkage  between  the 
headquarters  and  the  combat  unit. 

12.  The  capability  of  army  pallet  riggers  to  rig 
airdrop  pallets. 

The  following  sections  of  this  chapter  describe  the 
development  of  the  model.  The  next  section  starts  with  a 
listing  of  the  variable  names  and  definitions.  Next,  the 
parameters  used  in  the  model  are  provided  with  their  names 
and  definitions.  Then,  the  subscripts  used  in  this 
formulation  along  the  with  a  definition  of  the  values  each 
can  take  on  is  given.  The  following  sections  describe  the 
formulation  of  the  objective  function  and  the  formulation  of 
the  constraints.  At  the  end  of  the  chapter  a  summary  of  all 
the  equations  used  is  presented. 

Decision  Variables 

The  first  four  variables  presented  are  the  same 
variables  used  in  the  previous  formulations  by  Cooke, 

Tate,  and  Halle  ( 6 : 46-48, 14 : 27-29, 28 :ch3-l toch3-2 ) .  These 
variables  are : 

x(i,j,k,l):  The  number  of  type  i  aircraft  loads  on 

type  j  mission  of  type  k  cargo 
delivered  in  period  1  [ac/period] 


u  (  y,  m,  1  )  : 


The  number  of  type  y  units  deployed  by 
method  m  in  period  1  [units/period] 
(14:27). 


A(k,  1  )  : 


F  (  k  ,  1  )  : 


The  following 
NUM( 1,1)  : 


P(l)  : 


TRK I N ( 1  )  : 


The  excess  aircraft  type  k  payloads, 
at  the  APOD,  in  period  1  available 
for  use  against  unit  requirements  in 
the  next  period  (14:27)  [tons  or 
people] . 

The  excess  aircraft  type  k  payloads, 
at  the  FOL,  in  period  1  available  for 
use  against  unit  requirements  in  the 
next  period  (14:27)  [tons  or  people), 
variables  are  new  to  the  model: 

The  number  of  type  i  aircraft  available 
in  period  1  after  considering  the 
attrition  of  the  previous  periods 
( aircraft ] . 

The  excess  airdrop  pallets  in  period  1, 
available  for  use  against  airdrop 
requirements  in  the  next  period 
[standard  462L  pallets). 

The  number  of  transportation  units 
carrying  supplies  from  the  APOD  to  the 
FOL  in  period  1  [units). 


Model  Parameters 

This  section  gives  the  names  and  explanations  of  the 
parameters  used  throughout  the  model.  Many  of  these 
parameters  were  borrowed  from  the  previous  works;  although 
many  of  the  names  were  changed  to  make  the  equations  more 
descriptive  (6:47-50, 14:29-32, 28:ch3-2toch3-5) . 


AB  ( y ) 


AT  ( y ) 


ADC  (  i 


The  airdrop  Indicator  for  unit  type  y, 
equals  1  if  unit  is  to  be  airdropped  at  the 
front,  0  if  airland  (28:ch3-2). 

The  anti-tank  capability  of  type  y  unit 
[TOW  equivalents]  (28:ch3-2). 

The  airdrop  capacity  of  type  i  aircraft 
[standard  463L  pallets)  (14:29). 


ATRT ( i , j ) :  The  attrition  rate  of  type  i  aircraft 
flying  on  type  j  mission  [%  of  missions 
flown]  (14:29). 

CI(y):  The  combat  indicator  of  type  y  unit:  1  if 

combat  unit,  -1  if  combat  support,  0  if 
ne  ither  ( 28 : ch3-2 ) . 

CARGO(i,k):  The  capacity  of  type  i  aircraft  with 

type  k  cargo  [ tons/a ircraf t  or 
people/aircraft ]  ( 28  :ch3-3  )  . 

CPI(l):  The  combat  power  index  for  arriving  at  the 

front  in  period  1  (28:ch3-3). 

DISUSAP:  The  distance  between  the  US  and  the  APOD 

[nautical  miles]  (28:ch3-3). 


DISUSFO:  The  distance  between  the  US  and  the  FOL 


DISAPFO: 


FP  (  y )  : 


[nautical  miles)  (28:ch3-3). 


The  distance  between  the  APOD  and  the 


FOL  [nautical  miles]  (28:ch3-3) 


EAS ( i , k ) :  The  standardization  factor  for  the  MHE 

required  to  unload  type  i  aircraft  with  type 
k  cargo  [%  of  maximum  requirement ]( 28 : ch3-3 ) 
FLT(y):  The  defensive  frontage,  front  line  trace 

capability,  of  type  y  unit  [kilometers] 


(  2  8  :  c  h  3  -  3  ) 


The  firepower  capability  of  type  y  unit 
( 28  :  ch3-3  )  . 


GAT ( 1 ) :  The  minimum  amount  of  anti-tank  power 

required  by  period  1  [TOW  equivalents] 

( 28  :ch3-3 ) . 

GFLT(l):  The  minimum  amount  of  front  line  trace 

required  by  period  1  [kilometers]  (28:ch3-3) 

GTMA( i ) :  The  average  scheduled  ground  time  at  the 

APOD  for  type  i  aircraft  to  offload,  onload, 
and  refuel  ( hours/a  1 rcra ft ]  (28:ch3-3). 

GTMF(i):  The  average  scheduled  ground  time  at  the 

FOL  for  type  i  aircraft  to  offload,  onload, 
and  refuel  [ hour s/a i rcra f t ] . 

INTER(i):  The  time  required  for  type  i  aircraft  to 

make  a  complete  intertheater  circuit  [days] 

( 28  :ch3-3 ) . 
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DISUSFO:  The  distance  between  the  US  and  the  FOL 


DISAPFO: 


EAS ( i , k ) : 


FLT(y)  : 


FP  ( y )  : 


GAT ( 1 )  : 


GFLT ( 1 ) : 


GTMA ( i ) : 


GTMF ( i ) : 


INTER ( i ) : 


(nautical  miles]  (28:ch3-3). 

The  distance  between  the  APOD  and  the 
FOL  (nautical  miles]  (28:ch3-3). 

The  standardization  factor  for  the  MHE 
required  to  unload  type  i  aircraft  with  type 
k  cargo  (%  of  maximum  requirement ]( 28 : ch3-3 ) 
The  defensive  frontage,  front  line  trace 
capability,  of  type  y  unit  (kilometers] 

( 28 :ch3-3 ) . 

The  firepower  capability  of  type  y  unit 
( 28 : ch3-3 ) . 

The  minimum  amount  of  anti-tank  power 
required  by  period  1  (TOW  equivalents] 

( 28 : ch3-3  )  . 

The  minimum  amount  of  front  line  trace 
required  by  period  1  (kilometers]  (28:ch3-3) 
The  average  scheduled  ground  time  at  the 
APOD  for  type  i  aircraft  to  offload,  onload, 
and  refuel  (hours/aircraft ]  (28:ch3-3). 

The  average  scheduled  ground  time  at  the 
FOL  for  type  i  aircraft  to  offload,  onload, 
and  refuel  ( hours/aircraf t  ]  . 

The  time  required  for  type  i  aircraft  to 
make  a  complete  intertheater  circuit  [days] 


NUM  (  i  )  : 


NUMTAC : 


PL  : 


PTVL(y) : 


RC: 


SPD  (  i )  : 


TON ( y , k  )  : 


TONC(y ) : 


TMCTRK  : 


TVL ( y )  : 


UN I T ( y )  : 


The  number  of  type  i  aircraft  dedicated  to 
this  deployment  at  the  beginning  of  the 
first  period  {aircraft]  (14:31). 

The  number  of  fighter  aircraft  assigned  to 
each  deployable  fighter  unit  [aircraft] 
(14:31). 

The  period  length,  in  this  model  a  period 
is  five  days  long  [days]  (14:31). 

The  length  of  time  it  takes  a  type  y  unit 
to  travel  from  the  APOD  to  the  FOL  on  its 
own  power  [number  of  periods]. 

The  army  rigger  capacity  [ pa  1 lets/day ] 
(28:3-4) 

The  cruise  speed  of  type  i  aircraft 
[nautical  miles/hour]  (28:3-4). 

The  amount  of  type  k  cargo  that  must  be 
moved  for  type  y  unit  [tons  or  people] 

( 28 :ch3-4 ) . 

The  supplies  consumed  by  type  y  unit 
[tons/day]  (28:ch3-4). 

The  daily  ton-mile  resupply  lift  capability 
of  a  transpor ta t i on  unit  [ ton*mi les/un i t/day ] 
( 28  :ch3-4  )  . 

The  distance  that  unit  type  y  can  travel  in 
one  day  [km/dayl  (28:ch3-4). 

The  number  of  type  y  units  available  for 


this  deployment  (28:ch3-4). 


UTE ( 1 , j ) :  The  utilization  of  type  i  aircraft  on  type 
j  mission  [hrs/day]  (28:ch3-4) 


Index  Values  for  this  Formulation 

The  scenario  used  in  this  formulation  require  the 
subscripts  to  take  on  certain  specific  meanings.  The 
range  of  each  subscript  and  the  meanings  of  each  subscript 
value  are: 

i:  a  specific  aircraft  type,  range  is  from  1  to  I. 

For  this  model  i  ranges  from  1  to  6  with  the 
following  aircraft: 

1=  C-5  Galaxy 
2=  C-17 

3=  C-141B  Starlifter 

4=  CRAF  Boeing  747  (cargo  type) 

5=  CRAF  McDonnell  Douglas  DC-8 
(personnel  type) 

6=  C-130/E  Hercules  (14:28) 

j:  a  specific  type  of  airlift  mission,  range  is  from 

1  to  J.  For  this  model  range  is  from  1  to  4. 

1=  Delivery  to  the  APOD  (  i nter theater ) 

2=  Direct  delivery  to  the  front 
( inter  theater  ) 

3=  Airdrop  missions  (intertheater) 

4=  Intratheater  missions  (14:28) 


APOD  to  FOL 


a  specific  cargo  type  range  is  from  1  to  K.  For 
this  model  k  ranges  from  1  to  5. 

1=  outsize 
2=  oversize 

3=  bulk  (including  supplies) 

4=  personnel  (14:28) 

5=  supplies 

a  specific  period,  range  is  from  1  to  4,  with 
each  period  covering  five  days  for  twenty  days 
total  (14:28) 

the  mode  of  delivery,  range  is  from  1  to  M.  For 
this  model  m  ranges  from  1  to  3. 

1=  delivery  to  the  front 

2=  delivery  to  the  APOD  and  remain  at  the 
APOD  or  move  to  the  front  on  their  own 
3=  delivery  to  the  APOD  and  move  to  the 
front  via  intratheater  airlift  (14:29) 
a  specific  unit  type,  range  is  from  1  to  Y,  For 
this  model  range  is  from  1  to  8. 

1=  Airborne  units  of  the  82ND  Airborne  Division 

2=  HQ  units  from  the  82ND 

3=  Air  Assault  Units  (AH-64  equipped) 

4=  Artillery  units  (155mm) 

5=  Mechanized  Battalion  (M-ls) 

6=  Aircraft  fighter  squadron  (F-16s) 

7=  Medium  truck  company 

8=  US AF  Airlift  Control  Element  (ALCE) 


All  combinations  of  the  subscripts  are  not  possible.  Fo 
example  C-5  aircraft  are  not  used  for  airdrop  or  di  'ect 
delivery  to  the  front.  These  restrictions  are  specified 
during  the  formulations  of  the  constraints  and  stated 
implicitly  in  the  assumptions  of  the  scenario. 

Objective  Function  Formulation 

Combat  power  has  three  components:  anti-tank 
capability,  defensive  frontaqe  ("the  capability  of  a  unit 
to  man  a  front  line,  or  hold  a  per imeter . . . ( 6 : 1 3 ) " ) ,  and 
firepower.  The  third  component,  firepower,  has  an 
interesting  attribute.  The  1981  Congress ional ly  Mandated 
Mobility  Study  stated  that  firepower  delivered  in  a  timely 
manner  can  be  up  to  six  times  more  effective  than  the  same 
amount  of  firepower  delivered  late  (5:40).  This  idea 
has  become  the  basis  for  this  model. 

The  objective  function  maximizes  the  time  dependent 
measure  of  combat  power,  firepower  delivered.  The  other 
two  measures  of  combat  power,  anti-tank  capability  and 
defensive  frontage  are  not  as  time  critical  yet 
they  are  still  very  important.  For  example  without  defensive 
frontage  an  F-16  squadron,  which  has  a  good  amount  of 
firepower,  could  not  hold  any  ground  and  would  be  overrun. 

In  order  to  keep  the  model  from  maximizing  firepower,  at 
the  expense  of  defensive  frontage  and  anti-tank 
capability,  the  model  incorporates  constraints  which 
require  minimum  amounts  of  defensive  frontage  and  anti¬ 
tank  capability  while  maximizing  firepower  delivered.  The 


individual  requirements  of  defensive  frontage  and  anti¬ 
tank  capability  are  set  for  each  period  by  experts 
familiar  with  the  specific  threat  scenario.  This  is 
covered  in  further  detail  in  the  constraint  formulation 
section. 

In  order  to  incorporate  the  concept  of  time 
dependence  in  the  model  a  combat  power  index,  CPI(l),  is 
used  (6:54-55).  This  combat  power  index  is  estimated  by 
experts  involved  with  the  current  scenario  or  is  obtained 
from  curves  generated  by  simulations.  This  combat  power 
index  decreases  over  time  and  gives  a  higher  value  of 
combat  power  delivered  to  units  delivered  early  in  the 
deployment . 

The  general  expression  for  firepower  delivered  to  the 
deployment  area  is 

Y  L '  M 

E  E  E  CPI  ( 1 )  *FP  ( y )  *u  ( y,  m,  1 ) 
y= 1  1=1  m= 1 

This  equation  states  that  a  measure  of  firepower 
delivered  is  equal  to: 

[combat  power  index/period  *  fire  power/unit  * 
number  of  units  deployed] 

and  is  summed  over  all  y  units,  all  previous  periods 
up  to  and  including  the  current  period  L',  and  over  all 
modes  of  delivery  m. 

This  equation  must  be  broken  into  the  different  modes 
of  delivery  to  the  deployment  area  because  if  the  unit  is 
delivered  to  the  APOD  Its  firepower  Is  not  available  until 


it  moves  to  the  front  on  Its  own  or  Is  airlifted  from  the 
APOD  to  the  FOL .  When  m=l  the  mode  of  delivery  is  direct 
to  the  FOL,  either  airdrop  or  airland,  and  the  firepower 
can  be  credited  as  soon  as  the  unit  is  delivered.  Under 
this  mode  of  delivery  the  expression  becomes 

L  ' 

E  E  CPI ( 1 ) *FP (y ) *u (y, 1, 1 ) 

y=l,3,4,5  1=1 

(14:34).  The  only  units  considered  to  be  delivered 
directly  to  the  front  are:  y=l,  82nd  Airborne;  y=3.  Aerial 
Assault;  y=4.  Artillery;  and  y=5.  Mechanized. 

When  m=2  the  unit  is  delivered  to  APOD  and  moves  to 
the  FOL  on  its  own  power  or,  if  not  destined  for  the  FOL, 
stays  at  the  APOD.  Under  this  mode  of  delivery  a  unit 
whose  destination  is  the  FOL  must  not  be  counted  as 
providing  firepower  until  It  actually  reaches  the  FOL. 

Thus  the  parameter  PTVL(y),  the  number  of  periods  it  takes 
a  unit  to  reach  the  FOL  on  its  own  power,  is  included  in 
the  model.  This  parameter  is  computed  as  the  nearest 
integer  to: 

DISAPFO  /  ( TVL ( Y ) *PL )  (28:ch3-7). 

When  m=2  the  objective  function  is 

L ' -PTVL 

E  E  CPI ( 1 ) *FP(y ) *u(y, 2, 1 ) 

y=l,3,4,5  1=1 

for  the  units  that  are  destined  for  the  front  --  the  82nd 
Airborne,  Airborne  Assault,  Artillery,  and  Mechanized.  Fo 
the  units  destined  to  remain  at  the  APOD  the  expression  is 


E  E 

y=2 , 6 , 7 , 8  1=1 


CPI(l)*FP(y)*u(y,2,l) 


These  units  include:  the  HQ82  Airborne,  F-16, 


Transpor ta t i on ,  and  ALCE  units. 

When  m=3  the  units  are  moved  to  the  APOD  and 


subsequently  moved  to  the  FOL  by  intratheater  airlift. 

The  firepower  is  assumed  to  be  available  in  less  than  one 
full  period  because  the  time  to  fly  from  the  APOD  to  the 
FOL  is  relatively  short  when  compared  to  the  period  length 
(28:ch3-7).  The  equation  becomes 


E  E 

y=l, 3,4,5  1=1 


CPI(l)*FP(y)*u(y,3,l) 


Again  the  only  units  considered  to  be  delivered  to  the 
front  are:  82nd  Airborne,  Aerial  Assault,  Artillery,  and 
Mechanized . 

The  completed  objective  function  becomes 
MAXIMIZE:  Fire  Power  Capability 


E  EE  CPI ( 1 ) *FP(y) *u(y,m, 1 ) 

y=l,3,4,5  1=1  m=l , 3 

L ’ -PTVL(y) 

E  E  CPI ( 1 ) *FP(y) *u(y, 2, 1 ) 

y=  1 , 3 , 4 , 5  1  =  1 


L  ’ 

E  E 

y=2, 6 , 7, 8  1=1 


CPI ( 1 )*FP(y)*u(y, 2, 1 ) 


This  objective  function  formulation  differs  from 
previous  efforts  in  that  both  Cooke  and  Tate  had  used 
multiple  goal  programing  techniques  and  had  Included  all 
three  measures  of  combat  power  in  their  objectives.  Haile 


used  an  objective  function  similar  to  the  one  presented 
above  except  he  included  a  term  for  combat  power  lost 
due  to  attrition.  The  formulation  in  the  current  model 
incorporates  attrition  implicitly  by  not  crediting  airlift 
with  the  delivery  of  cargo  from  attrited  assets.  This 
aspect  of  the  model  will  be  covered  in  more  detail  under 
the  shipment  of  units  constraints. 

The  next  section  begins  the  development  of  the 
constra  ints  . 

Constraint  Formulations 

As  stated  in  the  introduction  section  in  this  chapter 
many  factors  affect  the  capability  of  an  airlift  force  to 
deliver  combat  power  to  a  deployment  area.  This  section 
will  explain  the  logical  and  mathematical  development  of 
the  constraints  used  in  this  mathematical  programing 
problem . 

Combat  Power  Constraints .  There  are  three  measures 
of  combat  power,  as  stated  under  the  objective  function 
development  section.  The  first,  fire  power,  was  used  as 
the  variable  to  maximize  in  the  objective  function.  The 
other  two  measures  of  combat  power,  anti-tank  (AT)  and 
defensive  frontage  or  front  line  trace  (FLT),  will  be 
developed  as  constraints  requiring  minimum  amounts  of  each 
to  be  delivered  or  maintained  in  each  period. 


Anti-Tank  Constraint.  The  general  expression  for 
anti-tank  capability  delivered  to  the  deployment  area  is 

Y  L '  H 

E  E  E  AT(y)*u(y,m,l) 

y=l  1=1  m=l 

This  equation  states  that  a  measure  of  anti-tank 
capability  delivered  is  equal  to: 

[anti-tank  capability/unit  *  number  of  units  deployed] 
and  is  summed  over  the  current  period  and  all  previous 
periods  to  give  a  total  of  anti-tank  capability  delivered 
up  to  the  end  of  the  current  period. 

This  equation,  like  the  objective  function,  must  be 
separated  into  the  different  modes  of  delivery  . to  the 
deployment  area  for  the  different  units.  When  m=l, 
delivery  direct  to  the  FOL  either  airdrop  or  airland,  the 
anti-tank  capability  can  be  credited  as  soon  as  the  unit 
is  delivered.  Under  this  mode  of  delivery  the  expression 
becomes 

L ' 

E  E  AT (y)*u(y,l,l )  (14:34). 

y=l,3,4,5  1=1 

Once  again  as  in  the  objective  function  the  only  units 
to  be  delivered  directly  to  the  front  are:  82nd  Airborne, 
Aerial  Assault,  Artillery,  and  Mechanized. 

When  m=2,  the  unit  is  delivered  to  APOD  and  moves  to 
the  FOL  on  its  own  power  or,  if  not  destined  for  the  FOL, 
stays  at  the  APOD.  As  in  the  objective  function,  when 
this  mode  of  delivery  is  used,  a  unit  whose  destination  Is 
the  FOL  must  not  be  counted  until  it  actually  reaches  the 


FOL .  Thus  the  parameter  PTVL(y),  the  number  of  periods  it 

takes  a  unit  to  reach  the  FOL  on  its  own  power  must  again 
be  included.  When  m=2 ,  the  constraint  for  anti-tank 
capability  is 

L ' -PTVL 

E  E  AT (  y  )  *u  (  y,  2 ,  1  ) 

Y=l, 3,4,5  1=1 

for  the  units  that  are  destined  for  the  front:  the  8 2nd 
Airborne,  Aerial  Assault,  Artillery,  and  Mechanized.  For 
the  units  remaining  at  the  APOD  the  expression  is 

L  ' 

E  E  AT(y)*u(y,  2,1) 

y=  2 , 6 , 7 , 8  1  =  1 

These  units  include:  the  HQ82  Airborne,  F-16, 
transportation,  and  ALCE  (14:34). 

when  m=3,  the  units  are  moved  to  the  APOD  and 
subsequently  moved  to  the  FOL  by  intratheater  airlift. 

The  anti-tank  capability  is  available  in  less  than  one 
full  period  because  the  time  to  fly  from  the  APOD  to  the 
FOL  is  relatively  short.  The  equation  for  anti-tank 
capability  when  m=3  becomes 

L  * 

E  E  AT(y)*u(y, 3, 1 ) 

y=l,3,4,5  1=1 

Again  the  only  units  considered  to  be  delivered  to  the 
front  are:  82nd  Airborne,  Aerial  Assault,  Artillery,  and 
Mechanized  (14:34). 

The  completed  constraint  for  anti-tank  capability  is 
L  ' 

E  EE  AT ( y ) *u(y,m,  1  )  *■ 

y=  1, 3 , 4 , 5  1  =  1  m=l,3 


L'  -PTVMy) 

E  E  AT (y)*u(y,2/l)  + 

Y=l, 3,4,5  1=1 

L’ 

E  E  AT (y)*u(y,2,l)  >  GAT ( L ' ) 

y=2,6,7,8  1=1 

this  equation  states: 

[the  sum  of  anti-tank  capability  delivered,  previous 
periods  up  to  and  including  current  period  must  be  greater 
than  or  equal  to  the  anti-tank  requirement  for  the  current 
per iod 1 ( 14 : 35 ) . 

Defensive  Frontage  Constraint .  The 
constraint  development  for  the  defensive  frontage 
requirement  is  developed  similar  to  the  anti-tank 
requirement  just  covered.  This  equation  uses  the 
multiplier  FLT(y)  for  the  defensive  frontage  capability  of 
the  y  type  unit.  The  complete  equation  for  the  defensive 
frontage  requirement  is 

L  ' 

E  EE  FLT(y) *u(y,m,  1 )  + 

y=l, 3, 4, 5  1=1  m=l,  3 

L' -PTVL(y) 

E  E  FLT(y) *u (y, 2, 1 )  + 

y=l,3,4,5  1=1 

* 

L  ' 

E  E  FLT(y) *U(y, 2, 1 )  >  GFLT(L’) 

y=  2 , 6 , 7 , 8  1  =  1 

this  equation  states: 

(the  sum  of  defensive  frontage  capability  delivered, 
previous  periods  up  to  and  including  the  current  period  must 
be  greater  than  or  equal  to  the  defensive  frontage 
requirement  for  the  current  per iod ] ( 1 4 : 35 ) . 


Aircraft  Limitation  Constraints .  The  capability  to 

rapidly  deploy  troops  and  equipment  is  heavily  dependent 
on  the  availability  o£  airframes  and  on  the  number  of 
hours  per  day  each  airframe  can  be  expected  to  fly  for  a 
particular  mission.  This  section  develops  three  sets  of 
constraints  for  sortie  generation.  The  first  set  of 
constraints  accounts  for  the  total  number  of  aircraft  that 
have  been  dedicated  to  the  deployment  and  the  rate  of 
attrition  per  aircraft  type  mission  flown,  and  restricts 
the  number  of  aircraft  available  in  the  subsequent  period. 
The  second  set  of  constraints  uses  the  number  of  different 
aircraft  available  each  period.  These  constraints  limit 
the  number  of  individual  sorties  by  using  the  number  of 
days  it  takes  a  particular  aircraft  to  fly  a  particular 
mission  in  this  scenario.  The  third  set  of  constraints  in 
this  section  limits  the  number  of  sorties  by  looking  at  an 
overall  utilization  rate  per  aircraft  and  mission  type. 
This  utilization  rate  is  the  number  of  hours  per  day  a 
particular  aircraft  could  be  expected  to  fly  a  particular 
mission,  and  is  figured  by  "dividing  the  total  [annual) 
programmed  flying  hours  for  a  given  aircraft  type . . . by  the 
primary  aircraft  author i zed  ...  and  dividing  that  number  by 
160  to  get  an  expected  (daily)  usage  rate  (14:43-44)." 
These  last  two  sets  of  constraints  both  limit  the  maximum 
number  of  sorties  performed  by  the  aircraft. 

Attrition  Constraint.  Attrition  affects  the 
deployment  of  troops  and  equipment  in  a  number  of  ways. 


One  of  the  ways  is  by  keeping  certain  amounts  of  troops 
and  equipment  from  being  delivered  if  the  troops  and 
equipment  in  question  happen  to  be  on  an  aircraft  that  is 
shot  down.  Another  way  that  attrition  has  an  effect  is  by 
reducing  the  number  of  aircraft  available  for  use  in 
subsequent  periods. 

Attrition  is  aircraft  and  mission  specific.  For 
example,  certain  aircraft,  such  as  the  C-141,  without 
active  defensive  systems  may  be  very  susceptible  to  enemy 
attack  during  airdrop  missions  and  yet  be  relatively  safe 
during  airland  missions  at  the  APOD.  This  model  includes 
an  attrition  rate  which  is  a  fraction  of  missions  flown 
that  will  be  lost.  These  rates  are  determined  by  a 
detailed  analysis  of  each  aircraft  and  mission  type.  This 
parameter  is  ATRT ( i , j )  where  i  is  the  aircraft  type  and  j 
is  the  type  of  mission;  and,  is  related  to  the  number  of 
aircraft  per  period,  NUM(1,1),  by  the  following  equation 
When  L'  =  1  NUM ( i , 1 )  =  NUM(i) 

When  L'  =2,3,4  NUM (1,1)  =  Num( 1 ) 

L ' -1  J  K 

E  E  E  ATRT ( i , j  )  *  x(i,j,k,l) 

1  =  1  j  =  l  k  =  1 

[the  number  of  each  type  of  aircraft  for  a  given 
period  equals  the  number  of  that  type  in  the  first  period, 
minus  the  sum  over  all  previous  periods  of  the  product  of 
the  attrition  rate  for  that  aircraft  and  mission  type  and 
the  number  of  that  type  mission  flown). 


Aircraft  Usage  Sortie  Constraint.  The  number  of 

sorties  that  the  fleet  of  aircraft  available  for  the 
deployment  can  produce  is  directly  related  to  the  time  it 
takes  the  aircraft  to  fly  a  complete  circuit  of  a 
particular  type  mission.  This  time  would  not  only  include 
the  actual  flight  time  but  also  the  ground  time  required 
to  offload,  onload,  refuel  and  do  maintenance.  The 
estimates  for  these  times  were  added  together  to  determine 
the  total  time  for  a  particular  aircraft  to  complete  a 
mission  and  return  home  (or  to  the  APOD  for 
i ntratheater )  ready  for  another  mission  (14:40).  The  two 
parameters  INTER(i)  and  INTRA( i )  can  be  thought  of  as 
aircraft  days  required  for  an  aircraft  type  i  to  fly  a 
particular  mission  either  intertheater  or  Intratheater. 

The  constraint  to  restrict  the  sorties  is 

3  K 

INTER(i)  *  E  EE  x(i,j,k,l)  + 

i=l, 2, 3, 4, 5  j=l  k=l 

K 

INTRA(i)  *  E  E  X (  i , 4 , k ,  1  )  <  NUM ( i , 1 )  *  PL 

i=2, 3, 6  k~l 

(intertheater  aircraft  days  per  mission  times  number 
of  intertheater  missions  plus  intratheater  aircraft  days 
P e r  m 1 s s i o n  t i me s  n u mb e r  of  1  n t r a t h e a t e r  m i s s i o n s  m u s t  b e 
less  than  or  equal  to  number  of  aircraft  available  times 
period  length  in  days] 

Utilization  Rate  Constraint .  As  defined  earlier 
the  utilization  ( UTE )  rate  is  a  fleet  wide  average  hours 
per  day  of  expected  use  per  aircraft  type  for  a  specific 


type  of  mission.  The  surge  UTE  rate,  used  in  this 
formulation,  is  a  slightly  higher  than  normal  UTE  rate 
that  can  be  sustained  for  a  limited  period  of  time 
(usually  thirty  days ) ( 1 4 : 4 4 ) .  The  UTE  rate  restricts  the 
deployment  because  the  aircraft  involved  can  not  on  the 
average  fly  more  sorties  than  the  surge  UTE  rate  allows. 
Using  the  distance  from  the  US  to  the  APOD  as  a  standard, 
Cooke  developed  a  set  of  constraints  that  partitions  the 
use  of  a  particular  type  of  aircraft  into  the  four 
separate  missions  it  can  fly. 

The  basic  equation  that  forms  the  foundation  for  the 
UTE  rate  sortie  constraint  is 
Maximum  Sorties  = 

(PL  *  UTE ( 1 , j )  *  NUM(i)  *  SPD ( i ) )  /  (2  *  DISUSAP) 

(the  period  length  times  the  UTE  rate  times  the 
number  of  aircraft  times  the  speed  of  the  aircraft  equals 
the  total  miles  the  aircraft  can  fly  in  a  giver:  period; 
divided  by  two  (for  round  trip)  times  distance  from  US 
to  APOD  equals  the  total  number  of  sorties  available 
(6:58)1. 

UTE  rates  differ  depending  on  the  mission  being  flown 
and  are  usually  higher  for  the  long  legs  of  the 
Intertheater  missions.  Missions  with  higher  UTE  rates 
would  generate  more  sorties  when  everything  else  is  equal; 

'  but,  when  the  distance  between  APOD  and  FOL  (DISAPFO)  is 

shorter  than  DISUSAP,  the  ratio 


DISAPFO  /  DISUSAP 


times  the  number  of  Intratheater  (APOD  to  FOL )  missions 
can  convert  this  number  into  an  equivalant  number  of 
intertheater  (US  to  APOD)  missions.  A  similar  ratio  is 
used  to  convert  missions  direct  to  the  front,  both  airland 
and  airdrop,  into  equivalent  intertheater  missions.  This 
ratio  is 

DISUSFO  /  DISUSAP 

The  total  sorties  flown  must  be  less  than  or  equal  to  an 
equivalent  number  of  intertheater  missions  as  determined 
by  the  original  equation  above.  If  total  sorties  flown  is 
broken  down  by  mission  types,  the  ratios  discussed  above 
are  used,  and  both  sides  of  the  equation  are  divided  by 
the  UTE  rate  then  the  following  equation  evolves 

K 

E  E  1/UTE ( i  ,  1 )  *  x ( i , 1 , k , 1 )  + 

i  =  1 , 2 , 3 , 4 , 5  k  =  1 

K  DISUSFO 

E  E  E  1/UTE  (  i ,  j  )  *  -  *  x  (  i  ,  j  ,  k ,  1  )  + 

i =  2 , 3  k  =  l  j  =  2 , 3  DISUSAP 

K  DISAPFO 

E  E  1/UTE  (  i  ,  4  )  * -  *  x  (  i  ,  4  ,  k  ,  1  )  + 

i  =  2 , 3  k  =  1  DISUSAP 

<  PL  *  NUM ( i , 1 )  *  SPD(i)  /  (2  *  DISUSAP) 

(6:60,14:45).  The  first  term  above  accounts  for  all  US 

to  APOD  intertheater  missions.  The  second  term  includes  both 

airdrop  and  airland  at  the  FOL,  while  the  last  term  is  APOD 

to  FOL,  i ntratheater .  The  second  and  third  term  apply  only 

to  C-17  and  C-141.  This  constraint  does  not  apply  to  the  C-130 

sorties  which  are  strictly  intratheater  missions.  The  C-130 


constraint  is 


1/UTE (6,4)  *  x(6,4,k,l) 


<  PL  *  NUM (6,1)  *  SPD ( 6 )  /  (2  *  DISAPFO) 


(6:60,14:45) 


Airport  Facility  Constraints.  There  are  two  major 
factors  at  the  APOD  and  the  FOL  that  can  restrict  the  flow 
of  aircraft.  The  availability  of  parking  spaces  and  the 
capability  of  the  material  handling  equipment  ( MHE )  to 
offload  cargo  both  limit  the  number  of  sorties  that  can 
transit  the  facility.  There  are  four  sets  of  constraints, 
for  parking  and  two  for  MHE.  The  parking  constraint  is 
developed  first  followed  by  the  MHE  constraint. 

Airport  Parking.  Any  airfield  which  would  be 
considered  as  an  APOD  or  FOL  would  be  surveyed  and  the 
maximum  number  of  each  type  of  aircraft  that  can  simultan¬ 
eously  park  on  the  ramp  would  be  computed.  Headquarters 
MAC  has  a  large  data  base  of  airfields  worldwide  with  the 
maximum  on  the  ground  (MOG)  listings  already  computed.  To 
compute  ramp  saturation  with  different  types  of  aircraft 
in  the  scenario  a  linear  relationship  is  assumed.  For 
example,  if  an  airfield  ramp  can  handle  either  48  F-16s  or 
12  C-130s  then  the  airfield  can  simultaneously  hold  one- 
half  of  the  maximum  or  24  of  the  F-16s  and  one-half  of  the 
maximum  or  six  of  the  C-130s  (6:61).  This  linear  relation 
should  hold  for  all  but  the  smallest  of  fields  where  one 


large  aircraft  could  block  others  from  their  parking  spots 
(6:61). 


& 


The  basic  idea  behind  the  formulation  of  this 
constraint  is  to  break  each  type  of  sortie  flown  into  the 
APOD  or  the  FOL  into  the  percentage  of  ramp  that  aircraft 
on  those  missions  will  occupy  while  on  the  ground.  To  do 
this  the  parameters  GTMA(i)  and  GTMF ( i ) ,  the  average 
scheduled  ground  time  in  hours  at  the  APOD  and  FOL 
respectively  for  type  i  aircraft,  is  used.  The  ground 
time  is  multiplied  by  the  number  of  sorties  to  give  the 
total  amount  of  ground  time  required  for  a  given  number  of 
missions  of  a  certain  type  and  aircraft.  This  value  in 
turn  is  converted  to  a  percentage  of  the  total  ramp  space 
available  by  dividing  by  the  total  number  of  that  type 
aircraft  that  can  be  parked  on  the  ramp  times  the  period 
length  times  24  hours.  The  number  of  sorties  has  been 
converted  to  a  percentage  of  the  period-space  available  on 
the  ramp  (6:82). 

The  constraint  for  the  APOD  for  each  period  1'  is 
I  K 

CEE  GTMA(i)  *  X  (  i  ,  j  ,  k  ,  1  ' )  /  (  PL  *  NPRKA( i )  *  24  ) 
i  =  1  j  =  1 , 4  k  =  l 

1 ' 

+  E  u  ^  6  ,  2  ,  1  '  )  *  NUMTAC  /  NPRKAF16  <  =  1.0 
1  =  1 

The  first  term  accounts  for  all  missions  through  the 
APOD,  both  intertheater  and  intratheater  and  computes  the 
percent  of  the  ramp  used  per  period  by  each  type  mission 
and  aircraft.  The  second  term  reserves  parking  spots  for 
any  F-16  fighter  unit  that  is  delivered  to  the  APOD  and 
keeps  those  parking  spots  reserved  throughout  the 


deployment.  When  the  terms  on  the  left  side  of  the 
equation  equal  1  or  100%  the  ramp  is  completely  saturated 
(6:62)  . 

The  parking  constraint  for  the  FOL  is  formulated  the 
same  way  except  that  there  are  no  fighters  assigned  to  the 
FOL.  The  FOL  parking  constraint  is 
4  K 

E  EE  GTMF(i)  *  x(i,j,k,l')  /  (  PL  *  NPRKF(i)  *  24  ) 

i  =  2 , 3 , 6  j  =  2  k  =  l 


This  constraint  includes  C-17,  C-141,  and  C-130  aircraft 
flying  intratheater  between  the  APOD  and  the  FOL,  and  C-17 
and  C-141  aircraft  flying  airdrop  and  then  stopping  at  the 
FOL  to  refuel  (14:48). 

Material  Handling  Equipment .  The  material 
handling  equipment  constraints  look  at  the  number  of 
standard  pallets  that  each  type  aircraft  carries  on 
airland  missions,  and  takes  into  account  the  capacity  of 
the  material  handling  equipment  stationed  at  the  APOD  and 
the  FOL. 

The  number  of  pallets  that  fit  on  each  aircraft  type 
is  easy  determined.  The  amount  of  material  handling 
equipment  required  to  unload  different  types  of  cargo  is 
not  so  easily  calculated  (28:ch3-15).  To  account  for  the 
different  types  of  cargo  --  outsize,  oversize,  bulk,  and 
personnel  --  moved  in  this  model  the  ease  of  offload, 
EAS(l,k),  parameter  is  used.  For  example,  if  a  C-17  is 
loaded  with  M-l  battle  tanks  (outsize),  the  amount  of 


material  handlin'?  equipment  required  would  be  small  an  EAS 

=  .2,  since  the  M-l  can  drive  off  the  aircraft.  The  same 
aircraft  full  of  bulk  cargo  loaded  on  pallets  would 
require  the  most  material  handling  equipment  ( EAS  =  1.0). 
The  EAS  values  are  set  by  experts  using  historical  data 
for  each  aircraft  and  cargo  type. 

The  quantity  of  material  handling  equipment  located 
at  both  the  APOD  and  the  FOL  is  expressed  in  terms  of  the 
number  of  pallets  per  period  that  the  equipment  can 
handle.  An  ALCE  unit  adds  additional  capacity  to  either 
the  APOD  or  FOL.  Since  a  period  is  equal  to  five  days,  an 
ALCE  is  credited  with  an  average  one-half  of  its 
capacity  during  the  period  when  it  arrives  (28:ch3-16). 

The  MHE  constraint  for  the  APOD  for  period  1'  is 
I  k 

E  EE  EAS ( i , k )  *  MHE(i)  *  x(i,j,k,l') 

i=l  1  =  1,4  k  =  l 

l'-l 

E  MHEALCE  *  PL  *  u(8,2,l) 

1  =  1 

-  .5  *  MHEALCE  *  PL  *  u(8,2,l')  <  MHEAPOD  *  PL 

The  constraint  for  the  FOL  for  period  1'  is 

k 

EE  E  EAS ( i , k )  *  MHE(i)  *  x(i,j,k,l') 

1=2,. 3, 6  .1  =  2,4  k  =  1 

1 '  -1 

-  E  E  MHEALCE  *  PL  *  u(8,m, 1) 

1=1  m=l , 3 

-  E  .5  *  MHEALCE  *  PL  *  u(8,m, 1')  <  MHEFOL  *  PL 

m=l ,  3 

Both  sets  of  constraints  restrict  the  sorties  through  the 


APOD  and  the  FOL  to  be  no  greater  than  the  requirements  to 
upload  or  download  the  aircraft  minus  the  capabilities  of 
ALCE  units  previously  delivered  and  half  of  the  capability 
of  ALCE  units  delivered  this  period  and  must  all  be  less 
than  the  capabilities  of  the  material  handling  equipment 
stationed  there  (6:64).  Both  account  for  intertheater  and 
intratheater  missions  while  the  FOL  constraint  does  not 
include  a  requirement  for  offloading  airdrop  missions 
which  stop  at  the  FOL  for  refuel  only. 

Unit  L imi tat  ion  Constraints.  The  unit  limitation 
constraints  refer  to  the  eight  types  of  units  to  be 
delivered  during  the  deployment.  The  first  set  of 
constraints  restricts  the  number  of  units  deployed  to  the 
number  available  for  the  deployment.  The  second  set 
requires  that  all  the  four  types  of  cargo  required  by  a 
unit  be  delivered  in  the  proper  ratios  before  any  portion 
of  that  units  combat  power  can  be  applied.  The  last  set 
of  constraints  in  this  section  deals  with  unit  linkage,  or 
requiring  certain  types  of  units,  like  combat  support  and 
headquarters  to  be  deployed  along  with  the  combat  units. 

Unit  Limitation.  This  set  of  constraints 
restricts  the  number  of  units  deployed  to  be  less  than  or 
equal  to  the  number  available  for  the  deployment  (6:64). 
The  constraint  for  unit  limitation  for  each  type  unit  y  is 
3  L 

E  E  u ( y , m, 1 )  <=  UNIT(y) 

m=  1  1  =  1 

[the  sum  of  all  different  modes  of  delivery,  m,  over  all 


the  periods,  1,  of  each  unit  type,  y,  is  less  than  or 
equal  to  the  number  of  units  available] 

(  6:64, 14:50, 28:ch3-17)  . 

Shipment  Of  Units.  A  unit  consist  of  its 
personnel  and  the  outsize,  oversize,  and  bulk  tonnage  that 
belongs  to  it.  These  are  cargo  types  k  equal  one  to  four, 
when  the  proper  mix  of  cargo  type  components  of  a  unit 
have  been  delivered  then  that  percentage  of  the  unit  is 
considered  delivered  and  its  combat  power  is  counted.  In 
this  model  units  are  initially  shipped  either  to  the  APOD, 
direct  to  the  front,  or  airdropped  at  the  front.  The 
following  constraints  look  at  either  the  tons  of  each  type 
of  cargo  delivered  or  number  of  personnel  by  each  method 
of  delivery  and  allocates  these  numbers  to  the 
requirements  of  the  units  delivered.  Excess  tonnage 
delivered  in  a  period  becomes  the  variables  A(k,l)  and 
F(k,l)  which  are  excess  type  k  payloads,  at  the  APOD  and 
FOL  respectively,  available  for  use  against  unit 
requirements  in  the  next  period.  Initial  excess  tonnage, 

F ( k , 0 )  and  A(k,0)  are  assumed  to  be  zero  in  all  cases. 

Attrition  was  not  previously  considered  in  this  part 
of  the  model  and  this  allowed  units  to  be  credited  with 
delivery  of  all  cargo  shipped  even  if  aircraft  were  lost. 
Attrition  is  modeled  by  subtracting  one-half  the  attrition 
rate  times  the  cargo  times  the  number  of  missions.  The 
one-half  is  because  the  aircraft  is  just  as  likely  to  be 
lost  on  its  way  out  when  it  is  empty  as  on  its  way  in  when 


it  is  full. 


The  constraint  for  the  delivery  of  units  in  period  1' 
for  each  type  cargo  k,  k  not  equal  to  5  (supplies),  to  the 
APOD  is 
5 

E  CARGO { i , k )  *  x(lfl,k,l') 
i  =  1 

5 

E  .  5  *  ATRT (  i  ,  1 )  *  CARGO (  i  ,  k  )  *  x(i,l,k,l') 
i  =  1 

Y 

E  E  TON ( y ,  k  )  *  u(y,m, 1 ' ) 
y=l  m=2 

-  E  E  TON (  y ,  k  )  *  u  ( y, m, 1  ' ) 

y= 1, 3,4, 5,8  m=3 

+  A(k, 1  * -1 )  -  A( k , 1 '  )  =  0 

[the  total  tonnage  of  each  type  k  cargo,  k  not  equal  to  5, 
on  all  missions  to  the  APOD,  minus  attrited  cargo,  minus 
the  tonnage  required  of  type  k  cargo  of  all  units 
delivered  to  the  APOD,  m=2,  or  Delivered  to  the  APOD  and 
moved  with  intratheater  airlift,  m=3,  plus  excess  type  k 
cargo  from  last  period  minus  excess  type  k  cargo  this 
period  equals  zero]  (  6 : 6 4 , 1 4 : 50 , 2 8  :  ch3- 17  )  . 

This  constraint  essentially  sets  the  value  of  the  excess, 
A(k,l),  for  this  period.  In  this  constraint  when  y  equals 
2,  6, or  7,  m  cannot  equal  3  because  the  Headquarters,  F-16 
and  truck  units  remain  at  the  APOD  and  do  not  move  to  the 
FOL. 

An  additional  constraint  is  needed  to  insure  that 
cargo  delivered  to  the  APOD  and  requiring  Intratheater 
airlift  to  the  FOL  is  actually  moved  to  the  FOL.  This 


constraint  shows  that  not  all  units  are  destined  for  the 

FOL .  This  constraint  for  cargo  type  k,  k  not  equal  to  5, 

in  period  1*  is: 

E  CARGO ( i  ,  k  )  *  x(  i,4,k,l' ) 
i  =  2,  3,6 

-  E  .5  *  ATRT ( i , 4 )  *  CARGO ( i , k )  *  x(i,4,k/l') 
i=2, 3,6 

-  E  TON ( y, k )  *  u(y, 3, 1 ' ) 
y=l, 3, 4, 5, 8 

+  F ( k , 1  '  -1 )  -  F ( k , 1 '  )  -  0 

[the  sum  of  the  type  k  cargo,  k  not  equal  to  5,  on  the  C- 
17s,  C-141s,  and  C-130s  flying  intratheater  missions, 
minus  the  attrited  cargo,  minus  the  requirements  for  type 
k  cargo  of  the  82nd  Airborne,  Air  Assault,  Artillery, 
Mechanized  and  ALCE  units  plus  excess  type  k  delivered 
last  period  minus  excess  this  period  equals  zero! 

(14:51, 28:ch3-18> 

The  direct  delivery  of  units  to  the  FOL  is  considered 
next.  This  constraint  is  similar  to  the  constraint  for 
delivery  to  the  APOD  except  that  only  the  C-17  and  C-141 
are  capable  of  direct  delivery  to  the  FOL.  The  indicator 
AB ( y )  is  used  in  this  constraint  to  distinguish  between 
units  that  can  be  airdropped  and  those  that  must  be 
airlanded  at  the  FOL.  AB ( y )  equals  one  for  units  to  be 
airdropped  and  zero  otherwise.  The  formulations  of  this 
constraint  by  Tate  Included  a  (l-AB(y))  term.  By 
including  the  (l-AB(y))  in  this  constraint  units  that  are 
to  be  airdropped  when  directly  delivered  to  the  front  will 
not  count  against  the  cargo  directly  delivered  by  airland. 


The  constraint  for  type  k  ,  k  not  equal  to  5,  cargo  in 
period  1  '  is 

E  CARGO ( i,k)  *  x(  i, 2,k,  1  '  ) 
i  =  2 ,  3 

-  E  .5  *  ATRT (1,2)  *  CARGO ( i , k )  *  x(i,2,k,l') 

1  =  2,3 

-  E  ( 1 -AB { y ) }  *  TON ( y , k )  *  u ( y , 1 , 1 ' ) 
y=l,  3,  4,5,8 

+  F(k, 1 ' -1)  -  F ( k , 1  '  )  =  0 

[the  sum  of  cargo  type  k,  k  not  equal  to  5,  on  C-17  and  C- 
141  direct  to  the  FOL  airland  missions,  minus  the  attrited 
cargo,  minus  the  requirements  of  the  units  to  be  direct 
delivered  by  airland  to  the  FOL  plus  excess  from  last 
period  at  the  FOL  minus  excess  this  period  equals 
zero] (6:66, 14:51, 28: ch 3-18) 

The  last  method  of  delivery  is  direct  delivery  to  the 
FOL  by  airdrop.  The  only  two  aircraft  in  this  model 
capable  of  intertheater  airdrop  are  the  C-17  and  the  C- 
141.  The  indicator  AB(y)  as  discussed  in  the  last 
constraint  is  again  used  to  match  airdropped  units  with 
their  cargo  requirements.  This  constraint  for  cargo  k  ,  k 
not  equal  to  5,  in  period  1'  is 

E  CARGO ( i,k )  *  x ( i , 3 , k ,  1  '  ) 
i  =  2  ,  3 

-  E  .5  *  ATRT ( i , 3 )  *  CARGO ( i , k )  *  x(i,3,k,l') 
i  =  2 , 3 

-  E  AB ( y )  *  TON ( y , k )  *  u(y,l,l') 

y=l, 3, 4, 5, 8 


[the  sum  of  cargo  type  k,  k  not  equal  to  5,  on  C-17  and  C- 

141  direct  to  the  FOL  airdrop  missions,  minus  the  attrited 
cargo,  minus  the  requirements  of  the  units  to  be  direct 
delivered  by  airdrop  to  the  FOL  plus  excess  from  last 
period  at  the  FOL  minus  excess  this  period  equals 
zero]  (6:66,14:52, 28:ch3-19) 

unit  Linkage.  The  following  constraints  create  a 
linkage  between  the  different  type  of  units  --  combat, 
combat  support,  and  headquarters  --  deployed  in  this 
model.  This  set  of  constraints  sets  floors  and  ceilings 
for  different  types  of  units  deployed.  A  floor  would  be 
requiring  a  certain  type  of  unit  to  be  deployed  given  that 
other  units  are  already  deployed  (6:72);  for  example, 
requiring  one  headquarters  unit  be  deployed  for  every 
three  to  five  combat  units  deployed.  A  ceiling  would  be 


requiring  other  types  of  units  to  be  deployed  prior  to  the 
deployment  of  a  certain  unit;  for  example,  before  a  combat 
support  unit  can  be  deployed  a  combat  unit  must  be 
deployed  to  protect  it  (6:71). 

This  model  uses  a  unit  linkage  between  the  82nd 
Airborne  and  the  82nd  Headquarters  as  a  floor  constraint. 
The  ratio  desired  is  at  least  one  headquarters  per  five 
Airborne  battalions,  although  this  ratio  is  flexible.  In 
order  to  allow  at  least  two  battalions  to  be  delivered 
before  the  first  headquarters  unit  but  to  require  a  second 
headquarters  before  the  sixth  battalion  is  delivered,  a 
third  before  the  ninth,  and  so  on  the  following 
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constraint  for  units  delivered  is  used 

3  L  L 

E  E  u( l,m, 1 )  -  3  *  E  u( 2, 2,  1  )  <=  2 

m= 1  1=1  1=1 

(the  number  of  airborne  units  delivered  to  the  theater 
minus  three  times  the  number  of  headquarters  units 
(delivered  only  to  the  APOD)  must  be  less  than  or  equal  to 
twol (6:72,14:58, 28:ch3-25)  . 

The  requirement  to  have  at  least  as  many  combat  units 
as  combat  support  is  also  modeled.  The  combat  indicator 
C I ( y )  is  used  and  indicates  +1  if  a  unit  is  a  combat  unit, 
-1  if  a  unit  is  combat  support,  and  0  if  neither  such  as 
an  ALCE  unit.  This  constraint  for  units  delivered  is 

Y  3  L 

E  E  E  Cl (y )  *  u(y,m, 1 )  >=  0 

y=l  m=l  1=1 

(the  sum  of  all  the  units  deployed  times  their  respective 
combat  indicator  should  be  qreater  than  or  equal  to  zero] 
(6:71, 14:58, 28:ch3-24)  . 

Resupply  constraints.  The  model  would  not  be 
complete  if  it  did  not  include  the  resupply  of  the  units 
delivered  to  the  objective  area  and  the  resupply  of  the 
units  stationed  there  at  the  start  of  the  deployment.  a 
special  category  k=5  is  used  in  this  model  to  represent 
supplies  needed  by  the  units.  While  resupply  s-r*  . 
be  those  with  k  =  5,  the  capabilities  of  the  tit  :  i  •  '  ■ 

carry  supplies  are  the  same  as  to  carry  i  • 
the  capacities  to  carry  bulk  i -  ;  - !  •  • 

supp lies. 
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The  formulation  of  the  supply  constraints  in  this 
model  are  somewhat  different  from  previous  formulations. 
There  is  a  set  of  constraints  for  the  APOD  and  a  set  for 
the  FOL.  The  amount  of  supplies  coming  into  the  APOD  or 
FOL  (including  previous  period  excess)  minus  all  the 
demands  on  supplies  at  that  APOD  or  FOL  (including 
supplies  left  for  next  period)  must  equal  zero.  The 
constraints  for  the  supplies  carried  by  truck  units  will 
be  discussed  first  followed  by  the  development  of  the 
actual  APOD  and  FOL  supply  constraints. 

Truck  Capacity.  The  only  units  deployed  in  this 
model  that  possess  any  lift  capability  are  the 
transportation  units  delivered  to  the  APOD  during  the 
various  periods.  These  truck  units  have  a  capacity  to 
haul  a  fixed  number  of  tons  of  cargo  a  fixed  number  of 
miles  in  a  day  which  is  given  by  the  parameter  TMCTRK .  To 
determine  the  number  of  tons  of  supplies  that  a  truck  unit 
can  carry  from  the  APOD  to  the  FOL  in  a  period  the 
distance  from  the  APOD  to  the  FOL,  DISAPFO,  and  period 
length,  PL,  must  be  used  In  the  following  equation 
TMCTRK  *  PL  /  (2  *  DISAPFO) 

[((Ton  miles/day)  *  (days/period))  /  (round  trip  miles)] 
(6:68,14:54,  28:ch3-21).  This  is  the  number  of  tons 
of  supplies  that  each  truck  unit  deployed  can  deliver  to 
the  FOL  in  a  period  and  will  be  used  as  the  multiplier  for 
the  variable  TRKIN(l),  the  number  of  truck  unit  shipments 
in  period  1.  The  parameter  PTVL(y)  is  computed  for  each 


unit  that  can  move  to  the  front  on  their  own  including  the 
truck  unit  and  equals  DISAPFO/(PL*TVL(Y) )  the  distance 
between  the  APOD  and  FOL  divided  by  the  number  of  days  in 
a  period  times  the  distance  unit  y  can  travel  in  a  day  and 
is  the  number  of  periods  that  it  takes  unit  y  to  reach  the 
front.  The  variable  TRKIN(i)  is  new  to  model  and  is 
restricted  to  keep  truck  unit  shipments  less  than  the 
number  of  truck  units  previously  deployed.  The  constraint 
for  period  1*  is 

1'-  PTVL ( 7 ) 

TRKIN( 1 ' )  -  E  u{ 1 ,  2, 1 )  <=  0 

1  =  1 

[the  number  of  truck  unit  shipments  in  a  period  minus  the 
number  of  truck  units  deployed  in  previous  periods  must  be 
less  than  or  equal  to  zero].  The  TRKIN(l)  variable  is 
used  in  the  APOD  and  FOL  supply  constraints. 

Supplies  at  the  A POD.  As  stated  earlier  the 
supply  constraint  at  the  APOD  will  be  the  supplies  brought 
into  the  APOD  plus  excess  supplies  last  period  minus 
demands  this  period  and  excess  this  period.  The  demands 
on  supplies  this  period  come  from  all  units  that  were 
delivered  in  previous  periods.  Storage  for  supplies  is 
considered  to  be  unlimited  although  the  model  gains 
nothing  for  delivery  of  an  excessively  large  amount  of 
supplies  above  the  quantity  needed.  The  units  delivered 
in  the  current  period  are  assumed  to  have  enough  supplies 
with  them  to  last  one  period.  Units  that  travel  to  the 
FOL  on  their  own  and  take  longer  than  one  period  to  reach 


the  FOL  will  continue  to  demand  supplies  at  the  APOD  until 

they  reach  the  FOL.  The  right  hand  side  of  this 
constraint  will  be  the  demand  for  supplies  that  existed  at 
the  APOD  prior  to  the  deployment  and  continues  through  the 
deployment  period.  The  constraint  for  supplies,  k  =  5,  at 
the  APOD  for  period  1'  is 
5 

E  CARGO ( i ,  3 )  *  x( i, 1, 5, 1 ' )  +  A(5,l'-1) 

i  =  l 

E  CARGO (  i  ,  3  )  *  x(i,4,5,l') 

1  =  2 , 3 , 6 

-  TMCTRK  *  PL/ (2  *  DISAPFO)  *  TRKIN(l') 
l’-l 

-  E  E  TONC(y)  *  u(y, 2,1) 

1=1  y=2, 6, 7, 8 

PTVL(y)-l 

-  E  E  TONC(y)  *  u(y, 2, 1 ) 

1=1  y=l,3,4,5 

-  A( 5, 1 '  ) 

=  TONCAPOD 

[The  tons  of  supplies  delivered  by  all  aircraft  flying 
intertheater  missions  to  the  APOD,  plus  the  tons  of 
supplies  left  after  the  last  period,  minus  the  tons  of 
supplies  moved  by  C-17s,  C-141s,  and  C-130s  on 
intratheater  missions  to  the  FOL,  minus  the  tons  carried 
by  truck  units  overland  to  the  FOL,  minus  tons  of  supplies 
required  by  all  units  delivered  to  and  remaining  at  the 
APOD  in  all  previous  periods,  minus  tons  of  supplies 
required  by  units  delivered  to  the  APOD  and  enroute  to  the 
FOL  on  their  own  and  traveling  longer  than  one  period, 
minus  excess  this  period  equals  the  tons  of  supplies 
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required  for  units  that  have  been  stationed  at  the  APOD 
since  the  start  of  the  deployment].  This  constraint 
essentially  Sets  the  excess  value  from  the  current  period 
to  be  used  in  the  next  period. 

FOL  Supplies .  Supply  requirements  at  the  FOL 
are  figured  the  same  way  as  at  the  APOD.  The  supplies 
brought  into  the  FOL  plus  excess  supplies  from  the  last 
period  minus  demands  this  period  and  excess  this  period 
equals  the  demand  of  the  units  stationed  at  the  FOL  at  the 
beginning  of  the  deployment.  The  demands  on  supplies  this 
period  come  from  all  units  that  were  delivered  in  previous 
periods.  The  units  delivered  in  the  current  period  are 
assumed  to  have  enough  supplies  with  them  to  last  one 
period.  The  constraint  for  supplies  at  the  FOL  in  period 
1'  is 

E  E  CARGO (  i  ,  3  )  *  x(i,j,5,l')  +  F(5,l'-1) 

1  =  2,3  J  =  2 , 3 

+  E  CARGO! i, 3)  *  x(i,4,5,l’) 

i  =  2 , 3 , 6 

+  TMCTRK  *  PL/(2  *  DISAPFO)  *  TRKIN ( 1 ' -PTVL ( 7 ) ) 
l'-l  3 

-  E  E  E  TONC(y)  *  u(y,m,l) 

1=1  y=l, 3,4,5  m=2 

1  • 

-  E  E  TONC(y)  *  u(y, 2,1) 

U-PTVL(y)  y=l,3,4,5 

-  F ( 5, 1 '  ) 

=  TONCFOL 

[the  tons  of  supplies  delivered  by  C-17s  and  C-141s  direct 
by  airdrop  and  airland  to  the  FOL,  plus  the  supplies  left 
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over  from  last  period,  plus  supplies  arriving  by 
intratheater  airlift  on  C-17s,  C-141s,  and  C-130s,  plus 
cargo  arriving  by  truck,  minus  the  tons  of  supplies 
required  by  all  units  delivered  in  previous  periods  by 
direct  delivery  and  intratheater,  minus  supplies  required 
by  all  units  that  have  arrived  on  their  own  in  previous 
periods  at  the  FOL,  minus  the  excess  supplies  this  period 
at  the  FOL  equals  the  tons  of  supplies  consumed  by  the 
units  stationed  at  the  FOL  prior  to  and  remaining  through 
the  deployment]. 

Airdrop  Pallet  Constraints .  This  constraint 
restricts  the  number  of  resupply  airdrop  sorties  by 
limiting  them  to  the  number  of  pallets  that  Army  riggers 
can  configure  in  a  period.  This  constraint  requires  a 
slack  variable  P(l)  which  Is  the  excess  supply  pallets 
rigged  for  airdrop  but  not  used  in  period  1.  The 
constraint  for  supply  pallets  rigged  in  period  1*  is 

E  ADC(i)  *  x( 1, 3, 5, 1 ' )  -  P(l'-l)  +  P(l')  =  RC  *  PL 
i  =  2 , 3 

[The  number  of  pallets  on  the  C-17s  and  C-141s  during 
airdrop  of  supplies,  minus  the  excess  pallets  rigged  for 
airdrop  last  period  plus  the  excess  pallets  rigged  this 
period  equals  the  rigger  capacity  per  day  times  the  period 
length  in  days] (6:73).  This  constraint  sets  the  excess 
each  period  to  be  used  in  the  next  period. 

Summary  Of  Formulation 

The  mathematical  formulation  of  this  model  has  been 


adapted  from  the  works  of  Captains  Cooke  and  Tate  and 
Major  Haile.  The  changes  have  been  noted  in  this  chapter. 
This  chapter  concludes  with  a  listing  of  the  objective  and 
constraint  equations  of  the  model  and  the  number  of  each 
required  for  the  model. 

--Objective  Function  Formulation 

MAXIMIZE:  Fire  Power  Capability  (one  for  model) 

L' 

E  E  E  CPI(l)*FP(y)*u(y,m,l)  + 

y=l,3,4,5  1=1  m=l,3 

L' -PTVL(y) 

E  E  CPI(l)*FP(y)*u(y,2,l)  + 

Y=l,3,4,5  1=1 

L' 

E  E  CPI (1 ) *FP(y) *u(y, 2,1) 
y= 2,6, 7,8  1=1 

--Constraint  Formulations 

- Combat  Power  Constraints 

- Anti-Tank  Constraint 

(one  for  each  period  1,  4) 

L' 

E  E  E  AT(y) *u(y,m, 1 )  + 

y=l,3,4,5  1=1  m=l,3 

L’-PTVL(y) 

E  E  AT(y ) *u(y, 2, 1 )  + 

y=l,3,4,5  1=1 

L' 

E  E  AT(y ) *u (y, 2 , 1 ) 

y=2,6,7,8  1=1 

>  GAT ( L  * ) 
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- Defensive  Frontage  Constraint 

(one  for  each  period  1,  4) 


e 

y=l/3/4/5 


E 

Y=l,3,4,5 


E 

y=2/6,7/8 


L* 

E  E  FLT(y)*u(y,m,l ) 
1=1  m=l/ 3 

L' -PTVL(y) 

E  FLT ( y ) *u ( y, 2 , 1 ) 

1  =  1 

L  ' 

E  FLT(y)*u(y,2,l) 

1  =  1 


>  GFLT(L') 


+ 


+ 


- Aircraft  Limitation  Constraints 


- Attrition  Constraint  (one  for  period  and 

aircraft  type  for  (L-l)  *  I  =  18  constraints) 

When  l'=l  NUM (  i  ,  1 )  =  NUM(i) 

l'-l  J  K 

When  l’=2,3,4  NUMfi,!)  +  E  E  E  ATRT ( i , j )  *  x(i,j,k,l) 

1=1  j=l  k=l 


=  Num( i ) 

- Aircraft  Usage  Sortie  constraint  (one  for  period 

and  aircraft  type  for  L  *  I  =  24  constraints) 

3  K 

INTER ( i )  *  E  E  E  x(i,j,k,l)  + 

1=1,2, 3,4, 5  j=l  k=l 


INTRA(i)  *  E 

i=2,3,6 


K 

E  x ( i , 4 , k , 1 )  -  NUM (1,1)  *  PL  <  0 
k  =  l 


- Utilization  Rate  Constraint  (one  for  period 

and  aircraft  type  for  L  *  I  =  24  constraints) 

K 

E  E  l/UTE(i,l)  *  x(i,l,k,l)  + 

i=l/2/3/4/5  k=l 

K  DISUSFO 

E  E  E  l/UTE(i,j)  * -  *  X(i,j,k,l)  +■ 

i  =  2, 3  k  =  l  j  =  2 , 3  DISUSAP 

K  DISAPFO 

E  E  1/UTE  (  i  ,  4  )  * -  *  x( i, 4,k,  1  )  + 

1=2,3  k=l  DISUSAP 

-  PL  *  NUM ( i , 1 )  *  SPD(i)  /  (2  *  DISUSAP)  <  0 

- The  c-130  constraint  is: 

K 

E  1/UTE (6,4)  *  x( 6, 4,k, 1 ) 

k  =  l 

-  PL  *  NUM (6,1)  *  SPD ( 6 )  /  (2  *  DISAPFO)  <  0 


- Airport  Facility  Constraints 

- Airport  Parking  (one  per  period  or  2*4=8  constraints) 

- The  APOD  constraint  for  each  period  1'  is: 

I  K 

E  E  E  GTM(i)  *  x( i, j,k,  1 ’ )  /  (  PL  *  NPRKA(i)  *  24  ) 
i=l  3=1,4  k=l 

1' 

+  E  u ( 6 , 2 , 1 ' )  *  NUMTAC  /  (  NPRKAF-16  *  PL )  <=1.0 

1  =  1 

- The  FOL  parking  constraint  is: 

4  K 

E  E  E  GTM(i)  *  X (  i , j , k, 1 '  )  /  (  PL  *  NPRKF ( i )  *  24  ) 

1  =  2, 3, 6  j  =  2  k  =  l 

<=  1.0 

- Material  Handling  Equipment  (one  per  period  or 

2*4=8  constraints) 


The  constraint  for  the  APOD  for  period  1'  is: 


k 

E  E  EAS (  i  ,  k  )  *  MHE (i)  *  x  (  i  ,  j ,  k ,  1  *  ) 

j  =  1, 4  k  =  l 

l’-l 

E  MHEALCE  *  PL  *  0(8,2,!) 

1  =  1 

-  .5  *  MHEALCE  *  PL  *  11(8,2,1*)  <  MHEAPOD  *  PL 

- The  constraint  for  the  FOL  for  period  1*  Is: 

k 

E  EE  EAS ( i , k )  *  MHE(i)  *  x(i,j,k,l*) 

i  =  2, 3, 6  j  =  2, 4  k  =  l 

l'-l 

E  E  MHEALCE  *  PL  *  u(8,m, 1) 

1=1  m=l, 3 

E  .5  *  MHEALCE  *  PL  *  U ( 8 , m, 1  * )  <  MHEFOL  *  PL 

m=l,  3 

- Unit  Limitation  Constraints 

- Unit  Limitation  (one  per  unit  y  =  8) 

3  L 

E  E  u(y,m, 1 )  <=  UNIT ( y ) 

m=l  1=1 

- Shipment  Of  Units 


I 

E 

i  =  l 


To  the  APOD  (two  per  unit  cargo  type 
and  period  or  2*4*4=32) 


m 


£  CARGO (  i ,  k  )  *  x  (  i  ,  1,  k ,  1 '  ) 

1=1 

5 

E  .5  *  ATRT(i,l)  *  CARGO (i,k)  *  x(i,l,k,l') 
i  =1 

Y  3 

-EE  TON(y,k  )  *  u(y,m,  1  •  ) 
y=l  m=2 


+  A( k, 1 ' -1 )  -  A(k,l  ' ) 


■v 


E  CARGO ( i,k  )  *  x(i/4/k/l>) 
i=2/3/6 

-  E  .5  *  ATRT( i / 4 )  *  CARGO (  i  ,  k  )  *  x(i,4,k,l') 
1=2,3, 6 

-  E  TON ( y, k  )  *  u (y, 3, 1 '  ) 

y=l, 3, 4,5, 8 


+  F{ k, 1 ' -1 )  -  F ( k , 1 '  ) 


0 


-To  the  FOL  (two  per  unit  cargo  type  and  period 
or  2*4*4=32) 


E  CARGO ( i , k )  *  x( i, 2,k, 1 '  ) 
i  =  2, 3 


I 


-  E  .5  *  ATRT (1,2)  *  CARGO ( i , k )  *  x(l,2,k,l') 
i  =  2,3 

-  E  (l-AB(y))  *  TON(y,k)  *  u ( y, 1 , 1  * ) 
y=l,3,4,5,8 

+  F( k, 1 ' -1 )  -  F(k, 1  '  )  =  0 

E  CARGO ( i , k  )  *  x( i , 3,k,  1 '  ) 

1  =  2,3 

-  E  .5  *  ATRT ( i , 3 )  *  CARGO ( i , k )  *  x(i,3,k,l') 

1  =  2,3 

-  E  AB(y)  *  TON ( y, k )  *  u(y,l,l') 
y= If  3, 4, 5, 8 

+  F(k, 1 ' -1 )  -  F(k, 1 '  )  =  0 


- Unit  Linkage 


Headquarters  (one  per  model) 


3  L  L 

E  E  u(l,m,l)  -  3  *  E  u ( 2, 2, 1 )  <  =  2 
m=l  1=1  1=1 

- Combat  Support  (one  per  model) 

Y  3  L 

E  E  E  CI(y)  *  u(y,m,l)  >=  0 

y= 1  m=l  1=1 

- Resupply  Constraints 

- Truck  Capacity,  (one  per  period  or  4) 

1'-  PT/L(7) 

TRKIN ( 1 ' )  -  E  u( 7, 2, 1 )  <  =  0 

1  =  1 

- Supplies  at  the  APOD  (one  per  period  or  4) 

5 

E  CARGO (1,3)  *  x(i, 1,5,1')  +  A( 5, 1 ' -1 ) 

i  =  l 

E  CARGO (1,3)  *  X( 1,4, 5,1') 
i =2, 3, 6 

-  TMCTRK  *  PL/ (2  *  DISAPFO)  *  TRKIN (1') 
l’-l 

-  E  E  TONC(y)  *  u(y, 2, 1 ) 

1=1  y=2,6,7,8 

PTVL(y ) -1 

-  E  E  TONC(y)  *  u(y,2,l) 

1=1  y= 1,3, 4,5 

-  A( 5, 1  '  ) 


TONCAPOD 


- POL  Supplies  (one  per  period  or  4) 

E  E  CARGO ( i , 3 )  *  x(i,j,5,l')  +  F(5,l’-1) 

i  =  2, 3  j=2, 3 

+  E  CARGO (1,3)  *  x(i,4,5,l'  ) 

i  =  2 , 3 , 6 

+  TMCTRK  *  PL/ (2  *  DISAPFO)  *  TRKIN ( 1 ' -PTVL ( 7 ) ) 
1 '  -1  3 

-  E  E  E  TONC(y)  *  u(y,m, 1) 

1=1  y=l , 3 , 4 , 5  m=2 

1' 

-  E  E  TONC(y)  *  u  ( y, 2 , 1 ) 

l+PTVL(y)  y=l,3,4,5 

-  F ( 5, 1 '  ) 

=  TONCFOL 

- Airdrop  Pallet  Constraints  (one  per  period  or  4) 

E  ADC(i)  *  X ( i , 3, 5, 1 1 )  -  P(l'-l)  +  P(l')  =  RC  *  PL 
i  =  2, 3 

Summary 

This  chapter  has  presented  the  complete  model  base  of 
this  DSS .  The  third  component  of  the  DSS,  the  man-machine 
Interface  Is  discussed  In  the  next  chapter. 


V.  Man-Machine  Interface 


Introduction 

This  chapter  contains  the  third  and  final  component 
of  this  DSS,  the  man-machine  interface.  This  component  of 
the  DSS  is  the  component  that  facilitates  the  user 
friendliness  of  the  DSS.  As  was  discussed  in  chapter  II 
a  characteristic  of  any  DSS  is  that  it  is  interactive 
and  user  friendly.  This  DSS,  which  uses  microcomputer  CRT 
and  keyboard  for  inputs  and  CRT,  disk  drive,  or  printer 
for  outputs,  is  interactive.  This  chapter  presents  the 
man-machine  Interface  of  this  DSS  by  first  describing  two 
feature  charts,  which  are  basically  wiring  diagrams 
showing  the  menus  used  in  this  DSS.  A  description  of  the 
Hookbook  and  Notepad  are  included  in  the  feature  chart 
section.  Next,  the  menus  are  presented  along  with  the 
built-in  help  function.  Lastly  a  brief  description  of  the 
input  screen  displays  and  a  description  of  the  output 
screen  displays  for  the  kernel  problem  identified  in 
chapter  II  is  given. 


Feature  Charts 

This  section  contains  two  feature  charts  of  this  DSS. 
Figure  2  is  the  feature  chart  for  the  input  spreadsheet 
and  Figure  3  is  the  feature  chart  for  the  output 
spreadsheet . 


A*' 


t'liivt'ty  * 


2.  Input  Feature  Chart 


Feature  Chart 


The  feature  chart  is  designed  to  show  the  user  the 
relationships  of  the  various  menus  available.  The  feature 
chart  incorporates  the  ROMC  design  approach  as  discussed 
in  chapter  II  and  can  be  used  to  show  the  representations, 
operations,  memory  aids  and  control  mechanisms  of  the  DSS 
(24:11-13) . 

These  feature  charts  contain  the  wiring  diagram  for  the  menus 
used  in  this  DSS.  These  menus  basically  lead  the  user  to  the 
screen  displays  to  view  and  change  the  data-bases  on  the  input 
side,  and  take  the  user  to  the  screen  displays  for  the  output- 
side.  Each  row  on  the  feature  chart  represents  a  menu, 
each  boxed  item  is  a  menu  selection,  and  the  lowest  box  in 
each  hierarchy  takes  the  user  to  a  screen  display.  The 
circled  letters  at  the  bottom  of  each  selection  represents 
either  the  menus  that  the  DSS  allows  you  to  easily  access 
from  that  screen  display  or  the  utilities  of  printing  and 
erasing. 

Hookbook  and  Notepad.  As  stressed  in  chapter  II  two 
important  parts  of  the  DSS  are  included  on  every  menu. 

They  are  the  hookbook,  for  the  user  to  leave  notes  for  the 
system  designer  and  builder,  and  the  notepad,  for  the  user 
to  leave  notes  to  himself.  These  two  screen  displays  are 
presented  in  Figures  4  and  5.  These  capabilities  of  this 
DSS  are  not  only  user  friendly  but  also  help  the  user  keep 
track  of  changes  identified  for  the  DSS.  This  feature 
supports  the  adaptability  required  in  a  DSS. 
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f  HOOKBOOK 


alt  p 
alt  e 
alt  c 
alt  a 
Esc 
notes : 


V* 


Use  this  area  to  enter,  review,  delete  or  print  i 

notes  to  the  systea  designer.  As  you  type  the  aessage 
will  apear  above  the  spreadsheet,  use  down  arrow 
when  at  the  end  of  a  line. 

Include  a  date,  a  label,  the  idea,  and  the  circumstances . j 
use  to  print,  highlight  with  arrow  keys  press  return, 
use  to  erase,  highlight  with  arrow  keys  press  return, 
to  return  to  change  menu 
to  return  to  aain  aenu 

use  Escape  key  if  error  is  made  when  highlighting. 

•»»  reainder  *»*:  date,  label,  idea,  circumstances  [ 


Figure  4.  Hookbook  Display 


MOTKPAD 


alt  p 

alt  e 

alt  c 

alt  a 

Bsc 

notes: 


Use  this  area  to  enter,  review,  delete  or  print  notes 
to  yourself.  As  you  typo  notes  they  will  appear  above 
the  spreadsheet,  use  down  arrow  key  when  you  are  at  the 
end  of  a  line. 

use  to  print,  highlight  with  arrow  keys  press  return, 
use  to  erase,  highlight  with  arrow  keys  press  return, 
to  return  to  change  menu 
to  return  to  aain  aenu 

use  Escape  key  if  error  is  aade  when  highlighting. 


Figure  S.  Mote pad  Display 


These  screen  displays  have  the  same  purpose  in  mind. 
Both  of  these  areas  in  the  DSS  are  designed  for  the  user 
to  leave  messages.  The  difference  is  that  in  the  case  of 
the  first  display  the  user  leaves  messages  to  himself  and 
in  the  case  of  the  second  the  user  leaves  messages  to  the 
system  designer  or  builder. 

The  basic  idea  on  these  two  screens  is  to  instruct 


the  user  how  to  leave  messages  and  to  give  him  the  memory 


5® 

ft 


aids  necessary  to  return  to  the  menu  desired.  The  "alt  x" 
areas  are  highlighted  in  green  to  draw  attention  to  them 
as  memory  and  training  aids.  Also,  on  the  hookbook  screen 
the  Instructions  to  include  the  date,  label,  idea,  and 
circumstances  are  highlighted  in  green  to  get  the  user  to 
follow  a  format  that  will  facilitate  communication  at  a 
later  date  of  the  ideas  entered  in  this  area. 

Menus 

This  section  gives  the  menus  and  the  descriptions  of 
each  menu  item.  It  begins  with  the  screen  display  the 
user  initially  sees  when  calling  up  the  input  spreadsheet. 
Then  the  input  and  output  menus  are  presented. 

Initial  Screen.  Figure  6  is  the  initial  screen 
display  and  main  menu  which  appear  when  the  user  calls  up 
the  input  spreadsheet. 


|VIEW|  CHANGE  NOTEPAD  HOOKBOOK  QUIT 
Use  to  Look  at  Decision,  Constraint,  or  Range  Names 

AC AH,  A  COMBAT  POWER  DELIVERED  DECISION  SUPPORT  SYSTEM 

j  the  menus  provided  above  the  spreadsheet  to  move  through  the 

|  different  tables  and  the  formulation. 

j 

Use  the  arrow  keys  to  move  within  the  tables. 

To  change  a  number  in  a  table  put  cursor  on  proper 
cell,  type  new  value  and  return. 

When  done  with  changes  in  a  table  select  appropriate  menu,  alt  x 
by  holding  down  [alt]  key  and  pressing  appropriate  letter. 


Figure  0.  Initial  Screen  Display 
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This  first  objective  of  this  screen  display  is  to 
tell  the  user  the  title  of  the  DSS.  This  representation 
shows  the  title  in  green  so  that  the  title  stands  out. 
Following  the  tittle  are  some  instructions  meant  to 
function  as  training  and  memory  aids  to  help  the  user 
control  this  DSS.  The  main  menu  appears  at  the  top  of  the 
display  to  allow  the  user  to  get  started  on  the  operations 
of  the  DSS.  Any  menu  item  can  be  selected  by  either  just 
selecting  the  first  letter  of  that  menu  item  or  by  using 
the  arrow  key  to  highlight  the  item  and  then  pressing 
return . 

An  important  memory  aid  and  training  aid  is  the 
explanation  of  the  menu  item  the  user  has  highlighted. 

This  explanation  appears  on  the  second  line  of  the  display 
under  the  menu.  The  two  ways  of  selecting  menu  items 
allows  the  user  to  use  the  help  explanations  if  needed  or 
bypass  them  if  already  familiar  with  the  menus. 

Input  Men  us.  The  development  of  menus  to  lead  the 
user  through  the  data  bases  and  the  output  of  the  linear 
program  model  requires  the  user  to  know  very  little  about 
the  software  used  for  this  DSS.  The  menus  for  the  input 
spreadsheet  are  shown  in  Figure  7  through  Figure  14.  The 
purpose  of  these  figures  is  to  show  the  help  explanations 
that  can  be  displayed  with  each  menu.  Each  two  lines 
in  these  figures  correspond  to  the  menu  and  the 
explanation  of  the  menu  item  selected  (boxed).  These  are 
the  displays  the  user  sees  at  the  top  of  the  spreadsheet. 


VIEWl  change  notepad  hookbook  quit 

Use  Co  took  at  Oteiilon,  Constraint,  or  Bangs  Vaasa 


VIEW  |  CHANGE  |  NOTEPAD  HOOKBOOK  QUIT 

Use  to  Changa  Paraaeters,  Bight-Hand  Sldos,  or  Forwulatlon 


VIEW 


CHANGE 


NOTEPAD 


HOOKBOOK  QUIT 


Move  to  tbs  notepad  where  notes  can  be  entered,  reviewed,  printed  or  deleted. 


VIEW  CHANGE  NOTEPAD  1 HOOKBOOK IqUIT 

A  place  to  leave  notes  on  ayatew  design  and  laproveaent  for  the  aanager. 


VIEW  CHANGE  NOTEPAD  HOOKBOOK IqUIT | 
Quit  the  DSS  Menu  and  Beturn  to  Lotus  123 


Figure  7.  Input  Main  Menu 


PARAMETERS 


REQUIREMENTS  FORMULATION  NOTEPAD  HOOKBOOK 


Allows  Selection  of  Different  Tables  of  Paraaeters  for  Editing 


PARAMETERS 


REQUIREMENTS  |  FORMULATION  NOTEPAD  HOOKBOOK 


To  Select  and  Change  Tables  of  AT  and  FLT,  Predeployaent  Supply  and  Rigger  Cap 


PARAMETERS  REQUIREMENTS  1 FORMULATIOnI  NOTEPAD  HOOKBOOK 

Places  You  at  the  Constraint  Matrix  for  Manually  Reworking  Foraulations 


PARAMETERS  REQUIREMENTS  FORMULATION  1  NOTEPAD  1  HOOKBOOK 

Move  to  the  notepad  where  notes  can  be  entered,  reviewed,  printed  or  deleted. 


PARAMETERS  REQUIREMENTS  FORMULATION  NOTEPAD  \ HOOKBOOK \ 

A  place  to  leave  notes  on  aystea  design  and  iaproveaent  for  the  aanager. 


Figure  B.  Input  Change  Menu 


I  AT  and  FLtI  SUPPLIES  BBQ  BIGGER  CAP  NOTEPAD  HOOKBOOK 
Use  to  set  Min  Requlreaents  for  Anti-Tank  and  Defensive  Frontage  per  Period 


AT  and  FLT  1  SUPPLIES  BEqI  RIGGER  CAP  NOTEPAD  HOOKBOOK 

Use  to  set  Tons  of  Dally  Supply  Reqd  at  APOD  and  FOL  Due  to  Peraanent  Units 

AT  and  FLT  SUPPLIES  REQ  |  RIGGER  CAp]  NOTEPAD  HOOKBOOK 
Use  to  set  A ray  Airdrop  Rigger  Capacity 


AT  and  FLT  SUPPLIES  REQ  RIGGER  CAP  |  NOTEPAD  |  HOOKBOOK 

Move  to  the  notepad  where  notes  can  be  entered,  reviewed,  printed  or  deleted  - 


AT  and  FLT  SUPPLIES  REQ 


RIGGER  CAP  NOTEPAD 


hookbook] 


A  place  to  leave  notes  on  systea  design  and  lM>roveaent  for  the  aanager. 


Figure  9.  Input  Requlreaents  Change  Menu 


[AIRCRAFT )  FIELDS  UNITS  COMBAT  VALUE  B07SPAD  HOOK BOOK 

Us*  this  to  Change  Aircraft  Numb «r*  and  Capabilities 

AIRCRAFT  [FIELDS I  UNITS  COMBAT  VALUE  NOTEPAD  HOOKBOOK 

Us*  this  to  Change  APOD  and  FOL  Parking  and  ME  Capabilities 

AIRCRAFT  FIELDS  (UMlTSl  COMBAT  VALUE  NOTEPAD  HOOKBOOK 

Us*  this  to  Chang*  Weights,  Capabilities,  and  Indicators  of  Units  to  Deploy 

AIRCRAFT  FIELDS  UNITS  1  COMBAT  VALUE  1  NOTEPAD  HOOKBOOK 

Use  this  to  Change  the  Caabat  Value  Over  Tine  Multipliers 


AIRCRAFT  FIELDS  UNITS  COMBAT  VALUE  1  NOTEPAD  )  HOOKBOOK 

Move  to  the  notepad  where  notes  can  be  entered,  reviewed,  printed  or  deleted. 

AIRCRAFT  FIELDS  UNITS  COMBAT  VALUE  NOTEPAD  1 HOOKBOOK 1 

A  place  to  leave  notes  on  systea  design  and  iaproveaent  tor  the  manager. 


Figure  10.  Input  Parameter  Change  Menu 


f  '  - . 

[  NUMBERS 

CAPABILITIES  INDICATORS  WEIGHT  SUPPLIES  NOTEPAD  HOOKBOOK 

Use  to  set  Nuaber  of  Units  Available  for  the  Deployment 


NUMBERS  IcAfARlLlTIKSn  INDICATORS  WEIGHT  SUPPLIES  NOTEPAD  HOOKBOOK 
Us*  to  set  Firepower,  Anti-Tank,  and  Defensive  Frontage  Capabilities 


NUMBERS  CAPABILITIES 


INDICATORS 


WEI  OUT  SUPPLIES  NOTEPAD  HOOKBOOK 


Us*  to  set  Combat  vrs  Combat  Support  and  Airdrop  Indicators 


NUMBERS  CAPABILITIES  INDICATORS [WEIGHT  [SUPPLIES  NOTEPAD  BOOK BOOK 
To  set  Ton*  of  Outsize,  Oversize  and  Bulk  and  Numbers  of  P0r0on»l  per  Unft 

NUMBERS  CAPABILITIES  INDICATORS  WEIGHT  lsUPPLIEsl  NOTEPAD  HOOKBOOK 
Use  to  set  Dally  Tons  of  Supplies  Consumed  by  Units 


NUMBERS  CAPABILITIES  INDICATORS  WEIGHT  SUPPLIES  1  NOTEPAD  1  HOOKBOOK 

Move  to  the  notepad  aher*  notes  can  be  entered,  reviemed,  printed  or  deleted - 

NUMBERS  CAPABILITIES  INDICATORS  WRIGHT  SUPPLIES  NOTEPAD  [ HOOKBOOK 1 
A  place  to  leave  notes  on  systea  deaign  and  iaproveaent  for  tb*  manager. 

^ _ _ _  ■  - - 


Figure  li.  Input  Units  Change  Menu 


|di stance!  ramp  material  handling  notepad  hookbook 

Use  lo  Change  Distance  Between  US  and  APOD  of  POL,  and  APOD  and  FOL 


DISTANCE 
Use  this  to 

DISTANCE 


RAMP 


MATERIAL  HANDLING  NOTEPAD  HOOKBOOK 


set  Airfield  Rasp  Capacities  for  APOD  and  FOL 


RAMP 


MATERIAL  HANDLING 


NOTEPAD  HOOKBOOK 


Use  this  to  set  Material  Handling  Equipment  Levels  at  APOD  and  FOL 

DISTANCE  RAMP  MATERIAL  HANDLING  (  NOTEPAD  1  HOOKBOOK 

Move  to  the  notepad  where  notes  can  be  entered,  reviewed,  printed  or  deleted- 


DISTANCE 


RAMP 


MATERIAL  HANDLING 


NOTEPAD 


HOOKBOOK 


A  place  to  leave  notes  on  systew  design  and  iwprovewent  for  the  manager 


Figure  12.  Input  Airfield  Change  Menu 


| FOR  AC  NUMBERS |  USAGE  PERFORMANCE  CARGO  ATTRITION  NOTEPAD  HOOKBOOK 

use  thid  to  Change  the  Number  of  any  Type  Aircraft  In  This  Model 

FOR  AC  NUMBERS  [USAUS|  PERFORMANCE  CARGO  ATTRITION  NOTEPAD  HOOKBOOK 

Use  this  to  Change  the  Usage  (round  trip  tiwes)  of  Each  Aircraft  Type 


FOR  AC  NUMBERS  USAGE 
Use  this  to  Change  Ute 


PERFORMANCE  1  CARGO  ATTRITION 
Rates,  Airspeeds  and  Ground  Tiwes 


NOTEPAD  HOOKBOOK 


FOR  AC  NUMBERS  USAGE  PERFORMANCE  |  CARGO  I  ATTRITION  NOTEPAD  HOOKBOOK 

To  Change  Tons, of  Each  Type  Cargo,  Nuwber  of  Pallets  and  Ease  of  Offload 

FOB  AC  NUMBERS  USAGE  PERFORMANCE  CARGO  | ATTRITION]  NOTEPAD  HOOKBOOK 

To  set  the  Attrition  Rate  for  each  Aircraft  and  Mission  Type 


FOR  AC  NUMBERS  USAGE  PERFORMANCE  CARGO  ATTRITION  |  NOTEPAD 3  HOOKBOOK 

Move  to  the  notepad  where  notes  can  be  entered,  reviewed,  printed  or  deleted. 

FOR  AC  NUMBERS  USAGE  PERFORMANCE  CARGO  ATTRITION  NOTEPAD  [HOOKBOOK] 

A  place  to  leave  notes  on  systew  design  and  iwprovewent  for  the  wanager. 


Figure  13.  Input  Aircraft  Change  Menu 


IDECISIQnI  CONSTRAINT  RANGE  NOTEPAD  HOOKBOOK 

Use  to  Look  at  the  Column  of  Decision  Variable  lames 

DECISION  I  CONSTRAINT!  RANGE  NOTEPAD  HOOKBOOK 

Use  to  Look  at  the  Row  of  Constraint  Names 

DECISION  CONSTRAINT  I  RANGE]  NOTEPAD  HOOKBOOK 

Use  to  Look  at  the  Column  of  Lotus  Range  Names  and  Locations  in  this  Model 
DECISION  CONSTRAINT  RANGE  I  NOTEPAD I  HOOKBOOK 

Move  to  the  notepad  where  notes  can  be  entered,  reviewed,  printed  or  deleted. 
DECISION  CONSTRAINT  RANGE  NOTEPAD  | HOOKBOOK  | 

A  place  to  leave  notes  on  system  design  and  improvement  for  the  manager. 
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Figure  14.  Input  View  Menu 


As  mentioned  earlier  the  last  item  in  the  menu 


hierarchy  will  take  the  user  to  a  data  base  screen 
display.  All  of  these  displays  have  been  presented 
earlier  in  Tables  I  through  XIII  of  chapter  III.  On  all 
thirteen  of  these  displays  operations,  memory  aids,  and 
control  mechanisms  are  provided  for  the  user  in  an  area 
the  display  which  contains  a  list  of  commands  used  to 
return  to  various  menus.  Returning  to  a  menu  is  as  easy 
as  holding  down  the  alt  key  and  pressing  the  letter  for 
the  menu  desired.  These  alt  x  commands  are  displayed  In 
green  to  draw  attention  to  their  location.  The  commands 
being  displayed  and  the  explanation  of  the  command  serve 


of 


•> 


$ 


as  memory  aids  to  the  user.  While  displaying  a  data  base 
table,  the  user  can  change  a  data  base  item  by:  first, 
using  the  arrow  keys  to  select  the  item,  second,  typing 
the  new  entry,  which  then  appears  on  the  top  line  of  the 
spreadsheet,  and  lastly,  pressing  return. 

Output  Menus.  The  menus  of  the  output  spreadsheet 
are  presented  in  Figures  15  through  20.  These  menus  are 
presented  in  the  same  way  as  the  input  spreadsheet  menus. 
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VIE*  1  CHANGE  OUTPUT  NOTEPAD  HOOKBOOK  QUIT 

Ui*to  Look  at  Doclalon,  Constraint,  or  Bangs  Names 

VIEW  |  CHANGE  |  OUTPUT  NOTEPAD  HOOKBOOK  QUIT 

Uaa  to  Cbanga  Parameters  or  Formulation  Conatrainta. 

VIEW  CHANGE  1  OUTPUT  1  NOTEPAD  HOOKBOOK  QUIT 

Oa#  to  Salact  Output  Analysis  Menu. 

VIEW  CHANGE  OUTPUT  }  NOTEPAD  1  HOOKBOOK  QUIT 

Wowa  to  the  notepad  where  notes  can  be  entered,  reviewed,  printed  or  deleted. 
VIEW  CHANGE  OUTPUT  NOTEPAD  | HOOKBOOK | QUIT 

A  place  to  leave  notes  on  system  design  and  laproveeent  for  the  manager. 

VIEW  CHANGE  OUTPUT  NOTEPAD  HOOKBOOK | QUIT  I 

Quit  the  DSS  Menu  and  Return  to  Lotus  123 


Figure  IS.  Output  Main  Menu 


PARAMETERS!  FORMULATION  NOTEPAD  HOOKBOOK 

Use  to  cTEange  Aircraft  Airdrop  or  Rigger  Capacities,  and  Unit  Indicators. 
PARAMETERS  I  FORMULATION]  NOTEPAD  HOOKBOOK 

Places  Tou  at  the  Constraint  Matrix  for  Manually  Reworking  Formulations 
PARAMETERS  FORMULATION  NOTEPAD  1  HOOKBOOK 

Move  to  the  notepad  where  notes  can  be  entered,  reviewed,  printed  or  deleted 
PARAIETERS  FORMULATION  NOTEPAD  I HOOK BOOK | 

A  place  to  leave  notes  on  system  design  and  improvement  for  the  manager. 


Figure  IS.  Output  Change  Menu 


| VARIABLES |  CONSTRAINTS  AC  SOBTIES  PATLOADS  GRAPH  NOTEPAD  HOOKBOOK 

Use  to  Look  at  Column  of  Decision  Variable  Activity  and  Reduced  Cost. 

VARIABLES  1  CONSTRAINTS*!  AC  SOBTIES  PATLOADS  GRAPH  NOTEPAD  HOOKBOOK 

Use  to  Look  at  Rows  of  Constraint  Left-hand  Sides  and  Dual  Value. 

VARIABLES  CONSTRAINTS  (AC  SOBTIES  ]  PATLOADS  GRAPH  NOTEPAD  HOOKBOOK 

Use  to  Look  at  Table  of  Total  Aircraft  Sorties  by  Aircraft  Type  per  Period 

VARIABLES  CONSTRAINTS  AC  SORTIES  | PATLOADS )  GRAPH  NOTEPAD  HOOKBOOK 

Use  to  Look  at  Table  of  Total  Aircraft  Sorties  by  Cargo  Type  per  Period. 


VARIABLES  CONSTRAINTS  AC  SORTIES  PATLOADS  |  GRAPH  |  NOTEPAD  HOOKBOOK 

Use  to  get  to  Chart  Menu  for  Chart  Options 

VARIABLES  CONSTRAINTS  AC  SORTIES  PATLOADS  GRAPH  (NOTEPAD  I  HOOKBOOK 

Move  to  the  notepad  where  notes  can  be  entered,  reviewed,  printed  or  deleted 

VARIABLES  CONSTRAINTS  AC  SOBTIES  PATLOADS  GRAPH  NOTEPAD  ( HOOKBOOK | 

A  place  to  leave  notes  on  system  design  and  Improvement  for  the  manager. 


Figure  17.  Output,  Output  Menu 


I  SAVg  PRINT  INPUTS  NOTEPAD  HOOKBOOK 

Us*  to  View  «  Graph. 

VIEW  ISAVgl  PRINT  INPUTS  NOTEPAD  HOOKBOOK 

Use  to  Sav*  Current  Graph  to  a  Picture  (.PIC)  File. 


VIEW  SAVE  1  PRINT  I  INPUTS  NOTEPAD  HOOKBOOK 

To  Print  a  Graph,  Save  it  and  Exit  the  Spreadsheet,  Use  Lotus  Printgraph. 

VIEW  SAVE  PRINT  | INPUTS  |  NOTEPAD  HOOKBOOK 

To  Look  at  the  Spreadsheet  Area  With  all  Graph  Inputs. 

VIEW  SAVE  PRINT  INPUTS  NOTEPAD  |  HOOKBOOK 

Move  to  the  notepad  where  notes  can  be  entered,  reviewed,  printed  or  deleted. 
VIEW  SAVE  PRINT  INPUTS  NOTEPAD  HOOKBOOK 

A  place  to  leave  notes  on  systew  design  and  improvement  (or  the  manager. 


SORTIES!  A,  C- 17  PAYLOADS  B.  C-141  PAYLOADS  NOTEPAD  HOOKBOOK 

Use  to  View  Graph  ot  AC  Sorties  by  Mission  Type,  PRESS  RETURN  and  Q  When  Done. 

SORTIES  | A,  C-17  PAYLOADS  B,  C-141  PAYLOADS  NOTEPAD  HOOKBOOK 
Use  to  View  Graph  ol  <5-17  Sorties  by  Payload  Type. 

SORTIES  A.  C-17  PAYLOADS  IB,  C-141  PAYLOADS]  NOTEPAD  HOOKBOOK 
Us*  to  View  Graph  of  C-141  Sorties  by  Payload  Type. 

SORTIES  A.  C-17  PAYLOADS  B,  C-141  PAYLOADS  HlOTEP AD  |  HOOKBOOK 

Move  to  the  notepad  where  notes  can  be  entered,  reviewed,  printed  or  deleted. 

SORTIES  A,  C-17  PAYLOADS  B,  C-141  PAYLOADS  NOTEPAD  [HOOKBOOK 
A  place  to  leave  notes  on  system  design  and  improvement  for  the  manager. 


Figure  IB.  Output  Graph  View  Menu 


DECISION  |  CONSTRAINT  RANGE  NOTEPAD  HOOKBOOK 
Us*  to  Look  at  the  Column  of  Decision  Variable  Names 

DECISION  [CONSTRAINT]  RANGE  NOTEPAD  HOOKBOOK 

Us*  to  Look  aV~th*  Row  of  Constraint  Names 


DECISION  CONSTRAINT  LRANOE [  NOTEPAD  HOOXBOOK 

Us*  to  Look  at  the  Column  of  Lotus  Rang*  Names  and  Locations  in  this  Model 
DECISION  CONSTRAINT  RANGE  [NOTEPAD)  HOOKBOOK 

Move  to  the  notepad  where  notes  can  be  entered,  reviewed,  printed  or  deleted. 
DECISION  CONSTRAINT  RANGE  NOTEPAD  [ HOOKBOOK I 

A  place  to  leave  notes  on  system  design  and  improvement  for  the  manager. 
Figure  20.  Output  View  Menu 
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As  new  uses  for  this  DSS  are  found  new  menus  can  be 


added  and  new  macros  can  be  created  to  accomplish  the 
new  task.  The  menus  are  built  in  modules  which  allows 
changes  to  be  made  without  affecting  any  previously 
developed  menus  or  macros. 

Output  Interface 

The  output  interface  of  the  DSS  is  required  to  be 
user  friendly  and  easy  to  understand.  The  screen  displays 
for  the  output  support  the  kernel  problems,  which  were 
identified  from  the  concept  maps.  The  kernels  dealt  with 
the  allocation  of  airlift  resources.  The  two  questions  to 
be  answered  were:  how  many  aircraft  sorties  of  what 
aircraft  and  mission  type  are  required  to  maximize  combat 
power  delivered  to  the  objective  area,  and  how  many 
aircraft  sorties  by  aircraft  and  payload  type  are  required 
per  period  to  maximize  combat  power  delivered  to  the 
objective  area? 

The  displays  for  the  output  from  this  DSS  are 
presented  in  three  ways.  Either  of  these  can  be  selected 
through  the  output  menu. 

The  first  way  to  view  the  output  is  through  selecting 
either  variables  or  constraints  from  the  output  menu. 

The  variable  selection  brings  to  the  screen  three  columns 
of  data.  These  three  columns  contain  the  variable  name, 
the  variable  activity  and  the  reduced  cost.  Table  XIV 
contains  the  variable  output  from  this  run  of  the  DSS 
mode  1 . 
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Table  XIV 
VARIABLE  OUTPUT 


VARABLE 

REDUCED 

NAME 

ACTIVITY 

COST 

FOL1  1 

0 . 000370 

F0L12 

0.001060 

FOL13 

0 . 000424 

F0L14 

0.002334 

FOL21 

FOL22 

FOL23 

FOL24 

0.002950 

F0L31 

0.003272 

FOL32 

810.5800 

FOL33 

810.5800 

FOL34 

810.5800 

FOL41 

FOL42 

F0L43 

F0L44 

0.000363 

FOLS31 

F0LS32 

FOLS33 

FOLS34 

0 . 002526 

APOD  1 1 

0.000352 

APOD  1  2 

0.001060 

APOD  1 3 

0.000424 

APOD 14 

0.002334 

APOD21 

APOD22 

APOD23 

APOD24 

0 . 003131 

APOD31 

APOD32 

AP0D33 

APOD34 

0.001870 

APOD4 1 
AP0D42 
APOD43 

APOD44 

0 . 000353 

APODS31 

APODS32 

APODS33 

APODS34 

0.001870 

PALI 

1000 

PAL2 

2000 

PAL3 

3000 

PAL4 

4000 

C5AP1 1 

90.90909 

C5AP12 

18.09917 

C5AP13 

18.08271 

C5AP14 

18 . 06628 

VARABLE 

REDUCED 

NAME 

ACTIVITY 

COST 

C5AP21 

0.061578 

C5AP22 

0.280198 

C5AP23 

0.202365 

C5AP24 

0. 171232 

C5AP31 

0. 151219 

C5AP32 

0.280198 

C5AP33 

0.202365 

C5AP34 

0. 171232 

C5AP41 

0. 185861 

C5AP42 

0.280198 

C5AP43 

0.202365 

C5AP44 

0. 171232 

C5AP51 

0. 151219 

C5AP52 

0.280198 

C5AP53 

0.202365 

C5AP54 

0. 171232 

C17AP1 1 

0.011247 

C17AP12 

19.74047 

C17AP13 

19.73060 

C17AP14 

19.72074 

C17AP21 

0.048637 

C17AP22 

0. 171826 

C17AP23 

0.  124097 

C17AP24 

0. 105005 

C17AP31 

0.  105406 

C17AP32 

0. 171826 

C17AP33 

0.  124097 

C17AP34 

0. 105005 

C17AP41 

0.  162861 

C17AP42 

0.  171826 

C17AP43 

0. 124097 

C17AP44 

0.  105005 

C17AP51 

0. 105406 

C17AP52 

0.  171826 

C17AP53 

0.  124097 

C17AP54 

0. 105005 

C17F01 1 

99.79949 

C17F012 

0.000629 

C17F013 

0.000334 

C17F014 

0 . 000105 

C17F021 

0.043423 

C17F022 

0. 172284 

C17F023 

0.  124307 

C17F024 

0.  105005 

C17F031 

0 . 057039 

C17F032 

0. 172284 

C17F033 

0 . 124307 

C17F034 

0. 105005 

Table  XIV  Icontinued) 
VARIABLE  OUTPUT 


VARABLE 

REDUCED 

VARABLE 

REDUCED 

NAME 

ACTIVITY 

COST 

NAME 

ACTIVITY 

COST 

C17F041 

0. 147549 

C141AP21 

28 . 62753 

C17F042 

0. 172284 

C141AP22 

1 1 .74832 

C17F043 

0 . 124307 

C141AP23 

36.82852 

C17F044 

0. 105005 

C141AP24 

6 . 953079 

C17F051 

0.061798 

C141AP31 

0.019591 

C17F052 

0. 172284 

C141AP32 

C17F053 

0. 124307 

C141AP33 

C17F054 

0.  105005 

C141AP34 

C17AD1 1 

C141AP41 

0.008871 

C17AD12 

C141AP42 

C 1 7 AD  1 3 

C141AP43 

3.651196 

C 17 AD  14 

C14 1AP44 

2.098030 

C17AD21 

0 . 082128 

Cl  4  1AP51 

0.019591 

C17AD22 

0 . 172857 

C141AP52 

C17AD23 

0 . 124569 

C141AP53 

C17AD24 

1 . 229293 

Cl  4 1AP54 

C17AD31 

0 . 025104 

C14  1F021 

191 . 7669 

C17AD32 

1 . 837971 

C141F022 

C17AD33 

0 . 124569 

C141F023 

C17AD34 

0. 105005 

C141F024 

C17AD41 

0. 138384 

C141F031 

16.75422 

C  17AD42 

0. 172857 

C141F032 

35.33093 

C17AD43 

0.684076 

C141F033 

C17AD44 

0. 105005 

C141F034 

C17AD51 

0.062958 

C141F041 

12.55965 

C17AD52 

0. 172857 

C141F042 

C17AD53 

0.  124569 

C141F043 

C17AD54 

0. 105005 

C141F044 

C17IN1  1 

0.032143 

C141F051 

0 . 002186 

C17IN12 

0.018316 

C141F052 

C17IN13 

0.012929 

C141F053 

10.20637 

C17IN14 

0.010500 

C141F054 

C17IN21 

0 . 035546 

C141AD21 

0.030783 

C17IN22 

0.018316 

C141AD22 

C17IN23 

0.012929 

C141AD23 

C17IN24 

0.010500 

C141AD24 

0 . 467279 

C17IN31 

C141AD31 

C17IN32 

0.018316 

C  1  4 1 AD 3 2 

0.764032 

C17IN33 

0.012929 

C141AD33 

C17IN34 

0 . 0  10500 

C14 1AD34 

C17IN41 

0 . 035826 

Cl  4 1AD4 1 

C17IN42 

0.018316 

C14 1AD42 

C17IN43 

0 .012929 

C141AD43 

0 . 831684 

C17IN44 

0 .010500 

C141AD44 

C17IN51 

2 . 0050  1  2 

C141AD51 

0 .017369 

C171N52 

0.018316 

C14 1AD52 

C 1 7 1 Nb3 

0.01 2929 

C  1 4  1AD53 

C17IN54 

0 . 0  10500 

C 14 1 AD54 

Table  XIV  (continued) 
VARIABLE  OUTPUT 


VARAbLE 

REDUCED 

VARABLE 

REDUCED 

NAME 

ACTIVITY 

COST 

NAME 

ACTIVITY 

COST 

0141 1N2 1 

0 . 023009 

C130IN51 

0.004664 

C  1 4  1  1  N22 

C130IN52 

C 1 4 1 l  N23 

C1301N53 

C 1 4 1 1 N24 

C130IN54 

C141IN31 

0 . 006832 

NUMC52 

7.981818 

C141IN32 

35. 41970 

NUMC53 

7.978228 

C  1  4  1  1 N33 

NUMC54 

7.974583 

C141IN34 

NUMC172 

7.948095 

C  14 1 IN41 

0. 026727 

NUMC173 

7 . 946121 

C1411N42 

NUMC174 

7.944148 

C 14 1 I N43 

NUMC1412 

21 . 77033 

C 14 1 IN44 

NUMC1413 

21 .64408 

C14 1 IN51 

0 . 006940 

NUMC1414 

21.62173 

C  14 1 IN52 

8 . 28  1029 

NUM7472 

5 . 985 

C  1 4  1 1  N  5  3 

NUM7473 

5.982015 

C 14 1 1 N54 

9 . 627031 

NUM7474 

5 . 980015 

C747AP2 1 

69 . 53362 

NUMDC82 

3 . 990090 

C747AP22 

9 . 47615b 

NUMDC83 

3.988113 

C747AP23 

3 . 063555 

NUMDC84 

3 . 9881 13 

C747AP24 

9.9271 12 

NUMC1302 

12 

0747AP31 

2.435081 

NUMC1303 

12 

0747AP32 

0 . 99371 1 

NUMC1304 

12 

C747AP33 

0 . 999623 

TRKIN1 

C747AP34 

0 . 643432 

TRK1N2 

C747 APb 1 

3.031289 

TRK1N3 

C747APb2 

4 . 455132 

TRKIN4 

C747APb3 

5 . 95855 1 

AB82F01 

C747APb4 

4 . 329508 

AB82K02 

DC8AP31 

13 . 86655 

AB82F03 

DC8AP32 

AB82F04 

DC8AP33 

AB62AP1 

9 

DC8AP34 

AB82AP2 

1 .832877 

DC8AP4 1 

35 . 68299 

AB82AP3 

3.832877 

DC8AP4  2 

2 . 240926 

AB82AP4 

4 . 632877 

DC8AP43 

AB821N1 

DC8AP44 

AB821N2 

1.832877 

DC8AP5 1 

AB82IN3 

3.832877 

DC8AP52 

7 . 644432 

AB82IN4 

4 . 632877 

DC8AP53 

HQ82AP1 

0.319525 

DC8AP54 

9 . 880460 

HQ82AP2 

C  1301 N3 1 

0 . 004664 

HQR2AP3 

2 . 333333 

C 1301N32 

HQ82AP4 

C 130 I N33 

AASSF01 

4 

C 130 I N34 

AASSK02 

2 . 326842 

C i 301 N4 1 

0.01 5344 

AASSF03 

5 . 197409 

C 1 30  1  N4  2 

AASSF04 

6.345636 

C 1301 N43 

AASSAP1 

0 . 007256 

C 1 30 1 N44 

AASSAP2 

2 . 326842 

Table  XIV  (continued) 
VARIABLE  OUTPUT 


VARABLE 

REDUCED 

VARABLE 

REDUCED 

NAME 

ACTIVITY 

COST 

NAME 

ACTIVITY 

COST 

AASSAP3 

5 .  197409 

MECH1N1 

AASSAP4 

6 . 345636 

MECHIN2 

AASSIN1 

0.000516 

MECHIN3 

AASSIN2 

2.326842 

MECH1N4 

AASS1N3 

5. 197409 

F16AP1 

0 . 594844 

AASSIN4 

6 . 345636 

F16AP2 

0.405155 

ART KOI 

1.21 1796 

F16AP3 

4 

ARTF02 

0.804214 

F16AP4 

5.6 

ARTF03 

2 . 260292 

TRKAP 1 

5.232757 

ARTF04 

2 . 842723 

TRKAP2 

ART API 

1 . 788203 

TRKAP3 

ARTAP2 

0 . 804214 

TRKAP4 

ARTAP3 

2 . 260292 

ALCEFOl 

0.465879 

ARTAP4 

2 . 842723 

ALCEF02 

ART  I N 1 

ALCEF03 

ART  1 N  2 

0.804214 

ALCEF04 

ART  l  N3 

2 . 260292 

ALCEAP1 

0 . 44  1064 

ART  1 N4 

2 . 842723 

ALCEAP2 

MECHFOl 

1 . 046918 

ALCEAP3 

MECHF02 

ALCEAP4 

MECHFOL 

ALCEIN1 

0.455707 

MECHF04 

ALCEIN2 

MECHAP1 

1 . 749292 

ALCE1N3 

MECHAP2 

0 . 587728 

ALCE1N4 

MECHAP3 

0.587291 

265 . 8907 

MECHAP4 

0.586853 

The  variable  activity  is  the  value  of  the  variable  at 
optimality.  The  reduced  cost  is  the  increase  in  the  value  of  the 
objective  function  associated  with  that  variable  required 
for  that  variable  to  enter  the  final  basses,  if  everything 
else  is  held  constant. 

Table  XV  contains  the  rows  of  data  assosiated  with 
the  constraints  selection  on  the  output  menu.  The  rows 
that  appear  on  the  screen  contain  the  constraint  name,  the 
constraint  activity,  and  the  constraint  dual. 


Table  XV 

CONSTRAINT  ACTIVITY  AND  DUAL 


constraint 
ac  1 1 v 1 ty 
dua  i 


cons  tra 1 n t 
ac  1 1 v 1 ty 
dual 


constraint 
act l v i ty 
dual 

constraint 
act l v i ty 
dual 


constraint 
act l v i ty 
dual 

constraint 
act i v l ty 
dua  1 


const ra  >  n  t 
act i v l ty 
d  ua  1 

cons  trai n  t 
act l v l ty 
dua  1 


constrai nt 
act i v i ty 
d  ua  1 


ANTI-TANK  REQU 1  RE ME NT 


PERIOD 

AT  1 

AT  2 

AT  3 

AT  4 

180 . 9265 

195.5121 

195.5121 

195. 5121 

--  FRONT 

LINE 

TRACE 

PERIOD 

FLT  1 

FLT  2 

FLT3 

FLT  4 

22 . 28150 

22 . 28150 

22 .28150 

22 .28150 

-  05  AIRCRAFT  GENERATION  - 

ONE  FOR  SOkTIE  ONE  FOR  NUMBER  OF  AIRCRAFT 


C5S1 

C52 

C5S2 

C53 

200 

40 

40 

0 . 122550 

0  .  127208 

0. 127208 

0.091913 

C5S3 

C54 

C5S4 

40 

0.091913 

0 . 077832 

0.077832 

-  C17  AIRCRAFT  GENERATION  - 

ONE  FOR  SORTIE  ONE  FOR  NUMBER  OF  AIRCRAFT 
C17S1  C 1 72  C17S2  C173 

200  40  40 

0.093481  0.085056  0.085856  0.062022 


C17S3 


C  1 74 


C17S4 


40 


0.062022  0.052502  0.052502 


-  C 1 4 1  AIRCRAFT  GENERATION  - 

ONE  FOR  SORT  IF.  ONE  FOR  NUMBER  OF  AIRCRAFT 
C141S1  C14  11  C14  1S2  C 1 4 1 2 

524 . 3875  110  -8. 83686  110 


C14 1S3 


Cl  4 13  C14  1S4 

110  -87.2099 


-  747  AIRCRAFT  GENERATION  - 

ONE  FOR  SORTIE  ONE  FOR  NUMBEH  OF  AIRCRAFT 


747S  1 

747  1 

747S2 

7472 

150 

30 

0 . 072802 

7473 


cons  tra l n  t 
act l v l ty 
dual 


7  47S3 
-9 . 77668 


30 


747S4 


CONSTRAINT  ACTIVITY  AND  DUAL 


- DC 8  AIHCKAKT  UfcNEHAT  I  ON - 

ONE  COK  SORTIE  ONE  KOH  NUMBER  OK  AIKCRAKT 


cons  tra i nt 

DOBS  1 

DC8  1 

DC8S2 

DC  8  2 

act l v l ty 
dual 

99 . 09909 

2  0 

-0 . 13018 

constraint 

DC8S3 

DC  8  4 

DCHS4 

ac  t i v i ty 
dual 

-19.881  1 

20 

-0. 12020 

-  C 1 30  AIRCRAFT  GENERATION  - 

ONE  FOR  SORTIE  ONE  FOR  NUMBER  OF  AIRCRAFT 
constraint  C130S1  C1301  C130S2  C1302 

activity  60  -60  60 

dual 

-  AIRCRAFT  UTILIZATION  RATE 

ONE  PER  C5  AND  PERIOD 

constraint  UC51  UC52  UC53  UC54 

activity  7.272727  -0.45314  -0.45359  -0.45404 

dual 

-  AIRCRAFT  UTILIZATION  RATE 

:  ONE  PER  C5  AND  PERIOD 

constraint  UC171  UC172  UC173  UC174 

activity  6.686515  -0.70775  -0.70789  -0.70803 

dua  J 

:  -  AIRCRAFT  UTILIZATION  RATE 

ONE  PER  Cb  AND  PERIOD 

constraint  UC 1 4 1  1  UC 1 4 1 2  UC14  13  UC1414 

activity  25.39414  -0.69167  -4.18068 

d  ua 1  0 . 57  5570 


-  AIRCRAFT  UTILIZATION  RATE 

ONE  PER  747  AND  PERIOD 

constraint  U7471  U7472  U7473  U7474 

activity  7.5  -0.02396  -0.51354  -0.02517 

dual 


-  AIRCRAFT  UTILIZATION  RATE 

ONE  PER  DC 8  AND  PERIOD 


cons  tra i n t 

UDC8  1 

UDC82 

UDC83 

UDC84 

ac  t i v i ty 

4 . 954954 

-0 . 98804 

dual 

0 . 568277 

Table  XV  (continued) 
COMSTRA I  NT  ACTIVITY  AND  DUAL 


-  AIRCRAFT  UTILIZATION  RATE 

ONE  PER  Cl  30  AND  PERIOD 

constraint  UC1301  UC1302  UC1303  UC1304 

activity  -20.25  -20.25  -20.25 

dual 


APOD  RAMP  CAPACITY 


constraint  A RAMP  1  ARAMP2  ARAMP3  ARAMP4 

activity  1  0.695034  0.633989  0.637336 

dual  10.58774 


FOL  RAMP  CAPACITY 


constraint  FHAMP1  FRAMP2  FRAMP3  FRAMP4 

activity  0.466634  0.123487  0.015947  0.015042 

dual 

APOD  MATERIAL  HANDLING  EQUIPMENT 
ONE  PER  PERIOD 

constraint  AMHE1  AMHE2  AMHE3  AMHE4 

activity  915.7659  890.4776  394.2624  457.7143 

dua  1 


FOL  MATERIAL  HANDLING  EQUIPMENT 
ONE  PER  PERIOD 


cons  trai nt 

FMHEi 

FMHE2 

FMHE3 

FMHE4 

ac  1 1 v i ty 

850 . 4725 

1027 .411 

132 . 6829 

125 . 1514 

dua  1 

8 2ND  AH 

82  HQ 

Air 

Assaul t 

Arti I lery 

cons  tra 1 n  t 

U82.ND 

082HQ 

UAASS 

UART 

activity 

9 

2 . 333333 

4 

3 

dual 

9 . 032877 

12 . 66088 

6 . 046094 

Meehan i zed 

Med i um 

Air  Force 

Ml 

F  1 6 

Truck 

ALCE 

cons  tra 1 nt 

UMECH 

UF16S 

UTRK 

UALCE 

act i v i ty 

4 . 558084 

1 

dual 

14.4 

Table  XV  (continued) 
CONSTRAINT  ACTIVITY  AND  DUAL 


cons  tra i n  t 

AP0UT1 

APOUT2 

AP0UT3 

acti v i ty 
dua  1 

-0.00417 

-0 . 00381 

-0 . 00275 

cons  tra 1 n  t 

AP0VR1 

APOVR2 

AP0VR3 

acti v i ty 
dua  1 

-0.00313 

constraint 

APBLK1 

APBLK2 

APBLK3 

act l vi ty 
dual 

-0 .00187 

cons tra i n  t 

APPER 1 

APPEK2 

APPEH3 

activi ty 
dua  l 

-0 . 00035 

cons  tra l n  t 

APFOOUT1 

APFOOUT2 

APF00UT3 

ac  1. 1  v  i  ty 
dua  l 

0 . 00000 

cons  traint 

APFOOVR1 

APFOOVR2 

APFOOVR3 

activi ty 
dual 

0.000064 

constraint 

APFOBLK 1 

APF0BLK2 

APF0BLK3 

acti v i ty 
dual 

-0 . 0006b 

constraint 

APFOPEH 1 

APF0PER2 

APFOPER3 

activi ty 
dual 

0 . 000033 

constraint 

F00UT1 

F00UT2 

F00UT3 

activity 

dual 

-0 . 00418 

-0 . 00381 

-0.00275 

constra l nt 

FOOVR1 

FOOVR2 

F00VR3 

acti v l ty 
dua  1 

-0 . 00301 

constraint 

F0BLK1 

F0BLK2 

F0BLK3 

acti v i ty 
dua  1 

-0 . 00262 

APOUT4 
-0 . 00233 
APOVR4 

APBLK4 

APPER4 

APFOOUT4 

APFOOVR4 

APFOBLK4 

APFOPER4 

FOOUT4 

-0.00233 

FOOVR4 

K0BLK4 


Table  XV  (continued) 
CONSTRAINT  ACTIVITY  AND  DUAL 


K 


E 


cons  tra 1 n  t 
act  1 v 1 ty 
dual 


cons  tra 1 n  t 
act  1 v 1 ty 
dual 


cons  tra i n  t 
act lvity 
d  ua  1 


cons  tra i n  t 
act i v i ty 
dual 


constrai nt 
act i vi ty 


cons  tra i n  t 
act i v i ty 
dua  1 


constrai nt 
acti vi ty 
dua  1 


E  OPER 1 

-o  00030 


FOPER2 


F0PER3 


FOPER4 


AIRDROP  MISSIONS  DIRECT  TO  THE  FRONT 
One  for  Each  Period  and  Cargo  Type 
ADOUTi  ADOUT2  ADOUT3  AD0UT4 


-0 . 0038b 
ADOVH2 


-0 . 00420 
ADO V  H 1 
-0 . 00223 
ADBLK1  ADBLK2 


-0 . 00277 
AD0VR3 


ADBLK3 


-0 . 00233 
ADOVR4 
0 . 02348  1 
ADBLK4 


-0.00328  0.03338b 
ADPEH1  ADPEH2  ADPER3 


ADPER4 


t: 

dual 

-0.00049 

0.005499 

■ 

SUPPLIES 

TO  THE 

APOD 

One  For 

Each  Period 

r-: 

constraint 

SUPAP1 

SUPAP2 

SUPAP3 

SUPAP4 

c> 

acti vi ty 

200 

200  200 

200 

dua  1 

-0.00187 

1 

SUPPLIES 

TO  THE 

FRONT 

One  For  Each  Period 
SUPF01  SUPF02  SUPF03 

100  100  100 
-0 . 002b2 


SUPF04 

100 


TRUCK  UNIT  SHIPMENTS 

Restricted  to  units  previously  delivered 
SUPTRKi  SUPTRK2  SUPTRK3  SUPTRK4 


-0 . 00074 

LINKAGE  COMBAT  AND 


SUPPORT  HDO 
constrai  n  L 1  NKSUP  1.1NKHDV 
activity  12.2247b  2 

dua  1 


RIGGER  CONSTRAINTS 
ONE  PER  PERIOD 
RIG  I  R1G2  RIG3 

1000  1000  1000 


R1G4 


1000 


123 


The  constraint  activity  depicted  on  this  display  is 
the  value  of  the  left  hand  side  of  the  constraint  at 
optimality.  The  dual  value  is  the  value  that  the 
objective  function  would  increase  by  if  one  more  unit  of 
that  constraint  resource  was  available,  everything  else 
remaining  the  same.  These  raw  data  outputs  are  not 
necessarily  as  useful  as  the  next  two  methods  of  output. 

The  second  way  the  output  is  displayed  is  in  a 
traditional  table  form.  Table  XVI  contains  the  output  for 
the  first  question  and  Table  XVII  contains  the  output  for 
the  second.  This  form  may  not  be  user  friendly  and  in  some 
cases  can  cause  user  overload  as  the  user  tries  to  plow 
through  the  rows  and  columns  of  numbers.  However, 
sometimes  this  much  detail  is  needed  and  can  show 

Table  XVI 


AIRCRAFT  SORTIES  PER  PERIOD  BY  AIRCRAFT  TYPE  AND  MISSION  TYPE 


INTERTHEATER  (OS  to  APOD) 

alt 

■ 

sain 

period 

TOTAL 

alt 

o 

output 

type 

1 

2 

3  4 

alt 

* 

graph 

C-5 

90.90909 

18.09917 

18.08271  18.06628 

145.1572 

C-  17 

0 

19.75 

19.74012  19.58811 

59.07823 

C  -  1 4  1 

0 

51.22383 

2. 100000  43.98628 

97.31011 

747 

75 

14.925 

14.91007  14.89516 

119.7302 

DC8 

49.54954 

0 

2.498286  2.  175389 

54.22322 

INTERTHEATER  (OS  to  F0L)  INCLOD I NG  i 

AIRDROP 

C- 17 

100 

0 

0  0 

100 

C-141 

242.9956 

0 

18.95406  7.059333 

269.0090 

INTRATHEATER  (APOD  to  FOL) 

C- 17 

0 

0 

0  1.421425 

1.421425 

C-141 

0 

0 

1.236334  14.70528 

15.94162 

C-  130 

0 

14.93157 

0  42.64671 

57.57829 

GRAND  TOTAL 


919.4495 


AIRCRAFT  SORTIES  BY  PAYLOAD  TYPE  PER  PERIOD 


IY  PAYLOAD  TYPE  PER  PEI 

HOD  alt 

■ 

main  menu 

al  t 

0 

output 

OUTSIZE 

alt 

t 

graph 

period 

TOTAL 

ac  type 

1 

2 

3 

4 

C-5 

90.90909 

IB 

.09917 

18 

.08271 

18.06628 

145.  1572 

C- 17 

100 

19.75 

19 

.74012 

21.00953 

160.4996 

OVERSIZE 

period 

TOTAL 

ac  type 

1 

2 

3 

4 

C-5 

0 

0 

0 

0 

0 

C- 17 

0 

0 

0 

0 

0 

C-141 

206.0752 

46 

.  13512 

4. 

058379 

23.90095 

281.3097 

747 

71.45091 

5. 

077752 

12 

.28700 

14.89516 

104.3109 

ac  type 

period 

1 

BULK 

2  3 

4 

TOTAL 

C-5 

0 

0  0 

0 

0 

C-  17 

0 

0  0 

0 

0 

C-141 

18.37012 

0  4.089876 

0.033436 

23.09944 

747 

3.549080 

1.820833  0 

0 

5.  175914 

DC8 

9.971192 

0  1.541843 

2. 175389 

13.68822 

C- 130 

0 

0  0 

0 

0 

ac  type 

period 

1 

PERSONNEL 

2  3 

4 

TOTAL 

C-5 

0 

0  0 

0 

0 

C-  17 

0 

0  0 

0 

0 

C-141 

13.58555 

5.088705  3.019417 

5.002735 

26.69641 

DCS 

34.74502 

0  0 

0 

34.74502 

C-  130 

0 

0  0 

0 

0 

ac  type 

period 

1 

SUPPLIES 

2  3 

4 

TOTAL 

C-5 

0 

0  0 

0 

0 

C- 17 

0 

0  0 

0 

0 

C-141 

4.358722 

0  10.52273 

30.21377 

51.09523 

747 

0 

7.820413  2.623008 

0 

10.24342 

DCS 

4.833334 

0  0.950642 

0 

5.789970 

C- 130 

0 

14.93157  0 

42.04071 

57.57829 

GRAND  TOTAL 


919.4495 


interesting  results.  On  these  two  tables  it  is  possible 
to  see  the  shift  in  aircraft  usage  as  the  periods 
progress . 

A  third  form  of  output,  which  many  consider  to  be 
superior  to  the  one  just  discussed,  is  graphical  output. 
Figures  21  and  22  show  the  graphical  output  built 
into  this  DSS.  The  graphs  are  of  aggregated  data  and  do 
give  easy-to-grasp  summaries  of  the  output  of  the  DSS. 
Another  user-friendly  aspect  of  this  DSS  is  that  the  user 
does  nothing  to  create  these  graphs,  he  just  selects  them 
from  the  menu  and  they  are  on  his  screen.  The  user  can 
select  save  from  the  graph  menu  and  save  the  most  recent 
graph  as  a  picture  (.PIC)  file  to  be  printed  with  Lotus 
Printgraph.  The  DSS  can  be  modified  in  less  than  five 
minutes  to  accommodate  new  graphical  output  identified 


US-APOD  l\\i  US-FOL  APOD-FOL 


F i gure 


Summary 

This  chapter  presented  the  man  machine  interface  of 
this  DSS .  The  feature  charts  were  presented  first  along 
with  a  discussion  of  the  notepad  and  hookbook .  The  menus 
were  presented  along  with  their  explanations  and  were 
followed  by  a  discussion  of  the  input  and  output  screens 
of  the  DSS. 


This  chapter  was  the  last  of  three  chapters  which 
described  the  three  components  of  the  DSS.  The  next 
chapter  will  discuss  the  evaluation  and  validation  of  this 
DSS,  and  conclussions  and  recommendat i ons  of  this  research 


W‘ 


VI.  Results,  Restrictions ,  and  Recommendations 

Introduction 

This  chapter  serves  three  purposes.  The  first 
purpose  is  to  present  the  results  of  the  research  effort 
and  relate  them  to  the  objectives  of  this  research.  The 
second  purpose  of  this  chapter  is  to  present  the 
restrictions  associated  with  this  DSS.  These  restrictions 
are  due  to  the  limitations  of  the  components  and  the 
software  of  the  DSS.  The  third  and  final  purpose  of  this 
chapter  is  to  suggest  some  recommendat i ons  for  further 
research . 

Results 

In  this  section  the  results  of  this  research  effort 
are  examined.  First,  the  results  are  presented  as  they 
relate  to  the  research  objectives  that  have  been  stated  in 
chapter  I.  Each  objective  is  restated  and  followed  by  a 
discussion  of  how  the  findings  of  the  research  effort  met 
that  objective.  Second,  the  validation  of  the  research 
and  the  evaluation  of  the  DSS  are  discussed. 

Objectives  and  Findings. 

I.  To  use  adaptive  design  in  building  a  decision 
support  system  (DSS)  which  incorporates  this 
mathematical  programming  model. 

The  primary  method  of  design  for  this  DSS  was  the 
adaptive  design  approach  as  discussed  in  detail  in  chapter 

II.  This  thesis  presents  one  complete  cycle  of  the 


adaptive  design  approach  with  a  working  prototype  as  the 


result . 

2.  To  solicit  specific  user,  HQ  MAC  Analysis 
Group,  requirements. 

Three  separate  trips  were  made  to  visit  the  HQ  MAC 
Analysis  Group.  The  first  trip  was  made  at  the  beginning 
of  this  research  effort  to  ascertain  the  extent  of  interest 
of  members  of  the  Analysis  Group  in  this  effort.  The 
second  trip  was  made  during  the  initial  design  stages  of 
the  DSS .  The  purpose  of  this  trip  was  to  identify  the 
requirements  of  the  Analysis  Group  by  using  the  concept 
mapping  technique  and  to  develop  the  storyboards  for  this 
DSS.  Analysis  Group  inputs  were  also  solicited  for  the 
model  impr ovments .  The  third  visit  to  Hq  MAC  was  used  to 
present  the  complete  prototype  to  the  Analysis  Group  and 
other  Interested  parties. 

3.  To  improve  the  modeling  of  attrition. 

This  was  a  recommendation  made  by  Haile  in  his  thesis. 
This  was  the  primary  improvement  made  to  the  mathematical 
programming  model.  This  improvement  as  well  as  the  other 
improvements  made  to  the  formulation  have  all  been 
identified  and  described  in  detail  in  Chapter  IV  the  model 
base  chapter. 

4.  To  adapt  the  model  to  accommodate  a  spreadsheet  to 
input  parameters  and  output  results. 

The  accomplishment  of  this  objective  was  a  big 
factor  in  the  successful  building  of  this  DSS.  Using  Lotus 
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123  as  the  DSS  generator  allowed  the  input  parameters  and 
output  results  to  be  displayed  in  user  friendly  tabular 
form. 


5.  To  develop  a  matrix  generator  to  easily  generate  the 
input  matrix,  objective  function,  and  right  hand  side 
for  the  mode  1 . 


This  objective  has  been  acomplished  and  was  a  major 
portion  of  the  effort  put  into  building  the  DSS.  Areas  of 
the  two  spreadsheets  required  for  this  DSS  have  been  set 
aside  for  the  matrix  for  the  mathematical  programing 
formulation.  The  matrix,  objective  function,  and  right 
hand  side  have  been  built  into  the  spreadsheet  in  such  a 
way  that  the  user  does  nothing  to  change  the  matrix  for  the 
formulation.  The  user  simply  changes  the  values  in  the 
parameter  tables  and  the  matrix  is  updated  automatically. 

The  next  three  objectives  six,  seven,  and  eight  are 
discussed  together. 

6.  To  Identify  the  size  of  formulation  required  to 
expand  the  model  from  the  current  four  five-day 
periods  to  thirty  one-day  periods. 

7.  To  identify  the  requirements  to  expand  the  model  to 
Include  more  than  one  aerial  port  of  debarkation 
(APOD)  and  forward  operating  location  (FOL)  . 

8.  To  develop  the  formula  that  will  determine  the  size 
of  the  problem  and  how  the  problem  grows  in  size  with 
each  of  the  changes  to  be  made. 

This  entire  discussion  on  increases  in  size  of  the 
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formulation  was  presented  in  the  model  size  section  of 
chapter  iv.  How  quickly  the  size  of  the  problem  grows 
with  various  changes  in  the  formulation  shows  that  changes 
should  be  studied  carefully  so  the  limits  of  the  software 
are  not  exceeded. 

9.  To  identify  with  the  help  of  the  user  and  a  technique 
called  concept  mapping  an  initial  problem  to  solve  as 
an  illustration  of  the  application  of  this  DSS . 

With  the  help  of  the  concept  mapping  technique  two 
kernels  were  identified  as  the  areas  for  this  prototype  DSS 
to  study.  Captain  Mark  Fowler  of  the  Hq  MAC  Analysis  Group 
was  the  user  that  participated  in  the  concept  mapping. 

The  application  of  this  DSS  to  the  study  of  the  kernel 
problems  identified  is  presented  throughout  this  thesis. 

All  the  tables  of  chapter  three  represent  the  data  base 
that  was  used  in  the  prototype  application  of  thl3  DSS. 
Tables  XVI  and  XVII,  and  Figures  21  and  22  of  chapter  V  are 
the  output  of  the  DSS  for  the  kernel  problems.  The 
objective  of  this  thesis  was  to  demonstrate  a  representative 
application  not  to  do  an  actual  study. 

Validation  and  Evaluation .  Both  validation  and 
evaluation  are  ongoing  processes  with  the  adaptive  design 
approach.  Validation  has  begun  with  the  various 
parameters  being  changed  and  the  model  run  a  dozen  times. 

The  values  of  the  variables  and  constraints  at 
optimization  have  been  checked  and  seem  consistent  with 
the  assumption  of  the  model. 


The  primary  evaluation  process  of  this  DSS  is  by 
reviewing  the  hookbook  entries  made  by  the  user.  The  user 
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will  leave  messages  on  system  performance  and  needed 
modifications  in  the  hookbook.  The  builder/designer  will 
review  these  entries  and  make  the  improvements  when 
necessary . 

The  adaptive  design  process  is  an  ongoing,  iterative 
process  which  requires  the  prototype  to  be  used  and 
modifications  and  additions  to  be  identified.  This  DSS 
has  been  presented  to  the  Analysis  Group  (AG),  the  Advanced 
Concepts  Requirements  Agency  (ACRA),  and  the  War  Plan 
Verification  Group  ( XOS )  at  HQ  MAC,  and  the  Studies  and 
Analysis  Branch  (J5)  of  USTRANSCOM.  Implementation  and 
subsequent  iterations  of  the  adaptive  design  seem  likely. 


Restrictions 

This  section  discusses  restrictions  on  the  use  of  this 
DSS.  These  restrictions  include  model  based 
restrictions  and  software/hardware  restrictions. 

Model  Restrictions.  The  restrictions  on  the  use  of 
the  DSS  due  to  the  model  are  all  due  to  the  assumptions 
that  are  built  into  the  model.  It  is  extremely  important 
to  take  into  account  the  assumptions  built  into  the  model 
for  any  analysis  that  uses  the  model.  The  assumptions  that 
pertain  to  the  variables,  constraints,  and  formulation  are 
all  outlined  in  chapter  IV. 

Software/Hardware  Restrictions .  This  DSS  was  designed 
on  a  Zenith  248,  IBM  AT  compatible  computer.  The  software 


used  was  Lotus  123,  as  the  DSS  generator,  and  XA  as  the 

mathematical  programming  solver. 

The  limitations  with  MS  DOS  and  Lotus  caused  the  DSS 
to  require  two  spreadsheets.  The  first  was  used  primarily 
for  input  while  the  second  contains  some  of  the  input  and 
all  of  the  output  of  the  DSS.  There  is  still  about  40%  of 
the  usable  space  on  the  output  spreadsheet  to  add  new 
output  tables.  If  changes  to  the  formulation  require  new 
variables  and  constraints  (in  this  case  rows  and  columns) 
to  be  added  to  the  mathematical  programming  matrix  then  the 
DSS  may  have  to  be  spread  over  additional  spreadsheets. 

The  limits  that  the  XA  linear  programming  software 
bring  to  this  DSS  are  with  respect  to  the  number  of 
variables  and  constraints  in  the  formulation.  The  largest 
version  of  the  XA  software  available  can  accommodate  1000 
constraints  and  5000  variables.  The  current  version  of 
this  DSS  with  338  variables  and  180  constraints  is  well 
below  the  limits  but  as  stated  earlier  to  go  to  30  periods 
would  require  1324  constraints  which  is  above  the  limits  of 
XA. 

The  computer  run  time  could  be  a  restriction  with 
Increased  formulation  size.  The  various  runs  of  the 
current  DSS  took  anywhere  from  a  few  seconds  to  20  minutes 
to  solve.  XA  is  fast  and  does  save  the  solution  from  the 
previous  run  to  use  as  a  start  for  a  subsequent  run. 

This  section  has  emphasized  the  fact  that  there  are 
assumptions  built  into  this  DSS  and  that  these  assumptions 


must  be  taken  into  account  when  using  this  DSS.  Also,  this 
section  has  presented  some  restrictions  on  this  DSS  due  to 
the  software  and  hardware  used  in  the  development  on  this 
DSS . 

Recommenda t i ons 

There  are  two  major  recommendations  for  future 
research  that  pertain  to  the  DSS  presented  in  this  thesis. 

1.  This  thesis  has  presented  one  complete  cycle  in  the 
adaptive  design  process,  with  the  prototype  DSS  having  been 
presented  to  various  users.  A  specific  user,  possibly  one 
whom  the  DSS  has  been  presented  to,  could  be  identified  and 
the  adaptive  design  process  continued  with  a  second 
iteration  of  the  process.  Improvements  and  modifications 
to  the  DSS  should  come  from  the  user. 

2.  This  DSS  could  be  used  to  accomplish  a  specific  study 
for  a  particular  user.  In  essence  the  researcher  would 
become  the  user  of  the  DSS  and  would  identify  a  specific 
study  to  be  accomplished  with  the  DSS.  An  example  of  this 
is  the  type  of  analysis  Haile  accomplished  with  an  earlier 
version  of  the  model. 

Noticeable  missing  from  these  recommendations  are  any 
specific  recommendations  dealing  with  modifications  to  this 
DSS  or  its  data  base  and  model  base.  This  is  intentional 
as  the  adaptive  design  process  requires  these  types  of 
recommendations  to  come  from  the  user. 


the  DSS  and  allows  the  DSS  to  function  as  an  interactive 
user  friendly  system.  This  component  contains  menus  and 
descriptions  for  individual  menu  items  for  both  the  input 
and  output  spreadsheets,  the  hookbook  and  notepad,  and 
tabular  and  graphical  output  screen  displays.  All  input 
data  screen  displays  contain  text  to  remind  the  user  of 
commands  available  to  return  him  or  her  to  various  menus. 

A  command  to  allow  easy  printing  of  any  part  of  the 
spreadsheets  is  included.  The  hookbook  and  notepad  are 
scratch  pads  within  the  spreadsheet  where  the  user  can 
leave  messages  for  himself  or  the  system  designer.  To 
study  the  kernel  problems  tabular  and  graphical  output  are 
both  included.  Depending  on  the  level  of  detail  required 
the  user  can  look  at  either  the  raw  data  output,  each 
variable  and  constraint  value,  or  the  tabular  output, 
aggregated  data  for  various  sorties,  or  the  graphical 
output,  aggregated  even  more  than  the  tabular  output. 

The  last  chapter  presented  the  results  and  findings  of 
this  research.  It  also  Included  a  summary  of  the 
restrictions  associated  with  this  DSS.  Lastly, 
recommendations  for  future  research  were  presented. 


Appendix 

This  is  a  short  users  guide  designed  for  the  user 
that  might  be  unfamiliar  with  the  operation  of  Lotus  123 
and  XA  and  is  intended  to  allow  easy  use  of  the  ACAR  DSS. 
The  system  was  built  on  a  Zenith  248  computer  (IBM  AT 
compat i ble ) . 

To  modify  the  ACAR  data  base  spreadsheet  the  user 
would  first  enter  Lotus  123  by  typing  LOTUS  and  selecting 
return.  When  the  Lotus  screen  appears  use  the  arrow  key 
to  highlight  123  and  select  return,  you  should  now  have  a 
blank  spreadsheet  on  the  screen.  Lotus  commands  are 
invoked  by  using  the  /  key  to  call  up  the  menus.  Menu 
items  are  selected  by  using  the  arrows  to  highlight  and 
return  to  select  or  by  pressing  the  first  letter  of  the 
menu  item  desired.  To  call  up  the  ACAR  spreadsheets  press 
/fr  (for  file  retrieve)  use  the  arrow  keys  to  highlight 
either  ACAR1  or  ACAR 2  and  press  return.  The  ACAR  screen 
appears  and  the  ACAR  menus  are  automat i ca 1 ly  available  at 
the  top  of  the  screen.  ACAR  menus  are  selected  the  same 
way  as  Lotus  menus.  To  call  back  a  menu  hold  the  alt  key 
and  press  the  letter  of  the  menu  desired. 

Sections  of  the  spreadsheet  can  be  printed  by  holding 
the  alt  key  and  pressing  p,  then  use  arrows  to  highlight 
the  material  to  be  printed  and  press  return. 

when  finished  with  changes  in  the  spreadsheet  select 
/fs  (to  save  the  file).  Exit  123  with  /q  and  a  yes. 

Exit  Lotus  by  highlighting  exit  and  pressing  return. 


To  invoke  the  XA  mathmatical  programing  optimization 


simply  type  ACAR  and  a  batch  file  will  be  started,  the 


matrix  will  be  read,  and  the  answers  will  be  placed  in  the 


ACAR 2  spreadsheet.  A  file  titled  ACAR . OUT  will  also  be 


created  with  the  standard  XA  output. 


Use  the  same  procedure  to  get  back  into  Lotus  and 


call  up  the  ACAR2  spreadsheet.  After  viewing  a  particular 


graph  and  if  saving  it  is  desired  select  save  from  the  graph 


menu  and  name  your  graph  with  a  .pic  extention.  To  print 


graphs  exit  123  and  highlight  printgraph  select  return  and 


follow  Lotus  printgraph  instructions. 


It  is  suggested  that  you  keep  the  original  ACAR  disk 


write  protected  and  in  a  safe  place,  use  only  copies  of 


the  original  disk  for  iterations  of  ACAR. 
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The  primary  objective  of  this  research  is  to  improve 
and  package  a  previously  developed  mathematical  programing 
model  to  increase  its  likelihood  of  acceptance.  The  model 
departs  from  the  normal  measure  of  effectiveness  of 
airlift,  measuring  ton  miles  per  day,  and  allocates  combat 
and  airlift  resources  to  maximize  combat  power  delivered  to 
the  objective  area  (thus  the  name  ACAR ) .  The  package 
selected  to  build  around  this  model  was  that  of  a  Decision 
Support  System  (DSS). 

This  thesis  has  produced  a  working  prototype  DSS  that 
can  assist  Air  Force  and  Army  Planners.  The  primary  method 
of  design  for  this  DSS  was  adaptive  design.  This  thesis 
presents  one  complete  cycle  of  that  approach.  The  concept 
mapping  technique  was  used  to  identify  two  kernel  problems 
for  this  DSS  to  study.  The  three  components  of  this  DSS, 
the  data  base,  the  model  base,  and  the  man  machine 
interface,  are  described  in  detail. 

The  data  base  component  consists  of  the  various  screen 
displays  which  contain  tabular  data.  The  tables  group 
similar  items  together  and  contain  the  input  required  to 
the  model  base  component.  The  heart  of  this  DSS  is  the 
model  base  which  has  been  adapted  from  previous  thesis 
efforts.  Lotus  123  was  used  as  a  DSS  generator  and  to 
generate  the  input  for  the  linear  programing  software 
called  XA.  This  DSS  is  a  user  friendly  analytical  tool. 


